On Thu, Jun 4, 2015 at 11:33 AM, Mat Booth <fedora@matbooth.co.uk> wrote:
On 4 June 2015 at 09:19, Noa Resare <noa@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, 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/c1a8a831b1ef0ec91509fea8066258629c215707

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@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=PackageMaintainers/Join



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.