On Thu, Jun 4, 2015 at 11:33 AM, Mat Booth <fedora(a)matbooth.co.uk> wrote:
On 4 June 2015 at 09:19, Noa Resare <noa(a)spotify.com> wrote:
> First off I would like to say that I'm very impressed by the effort you
> have put into java packaging over the last few years. Getting a usable
> environment for offline maven execution is no small feat.
>
> One thing I noted, however, was that the unit tests for the guava library
> was not run on package build. Which seems like a reasonable compromise but
> not ideal. I decided to look into what would be needed dependency wise for
> that to happen, and I came up with the following:
>
> * updates-testing needs to be activated for the auto-value dependency.
>
> * packages truth, allocation-instrumenter and caliper needs to be
> introduced. I have created those packages and built them with guidance from
> the Java Packaging HOWTO
> <
https://fedorahosted.org/released/javapackages/doc/>, the packages
> (SRPMS and mock built noarch.rpms) are available from
>
https://resare.com/noa-fedora-playground/repo/22 but please beware of
> newbie packaging mistakes :)
>
> * With the dependencies handled I updated guava.spec to re-enable
> guava-testlib and guava-tests. One test was consistently failing due to new
> java8 behaviour, and I back ported a fix from guava master. The changes
> needed can be viewed in my fork of
git://pkgs.fedoraproject.org/guava.git
> at
https://github.com/nresare/fedora-guava in the testlib-tests branch.
> The actual commit can be viewed here:
>
https://github.com/nresare/fedora-guava/commit/c1a8a831b1ef0ec91509fea806...
>
> I would love for my work to be of use in the fedora project and I'm
> willing to spend some time to land my contributions at this time. I will
> now read up on what I need to to contribute more formally.
>
> /noa
>
> --
> Spotify Free Software ombudsman. I/O Tribe.
>
> --
> java-devel mailing list
> java-devel(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/java-devel
>
This is great to hear -- it sounds like useful work you have done and I
look forward to seeing your new packages appear in Fedora :-)
I assume you have seen this document already:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd...
Thanks!
I hit a slight snag in my progression to publish the depenencies. It turns
out that one of the dependencies, caliper doesn't build in rawhide because
of a dependency on jersey-client:1.11. There is a compatibility package in
rawhide named jersey1 which provides jersey-client:1.19 but it seems like
the "fuzzy artefact resolution" going on works differently when depending
on compat packages and there needs to be an exact version match (updating
the dependency version to something jersey1 provides, such as 1.19 or 1
makes the package build.)
What is the best cause of action here? A, flip the dependency from 1.11 to
1.19. B, flip the dependency from 1.11 to 1. Any of those seems to have
potential to be "interesting" when some other code has it's more specific
dependency on jersey fulfilled transitively.
Another quick question: attempting to use the same copr project for both a
released version of fedora and rawhide doesn't make a lot of sense, in the
case of java with fast moving and complex dependencies, right? I assume
after having run into this that I would want one copr project per target so
that I can let the packages diverge.
/noa
--
Spotify Free Software ombudsman. I/O Tribe.