Thank you for all the useful feedback. In the latest few days, I have looked quite closely at the packages I prepared and concluded that the guava change to enable testlib and unit tests can be made much smaller if the caliper dependency is simply disabled.
The dependency is not used by the default maven build (caliper is a benchmarking framework and benchmarking, while useful, is not part of the code shipping or testing)
This means that we are down to a single extra dependency to be able to enable guava testing, the truth package.
I have submitted a review request and I'm looking for sponsors: https://bugzilla.redhat.com/show_bug.cgi?id=1229704
On Fri, Jun 5, 2015 at 8:30 AM, Mikolaj Izdebski <mizdebsk@xxxxxxxxxx> wrote:
On 06/04/2015 11:15 PM, Noa Resare wrote:
> 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.
IMHO compat packages should be used or introduced only as last resort,
mostly because they prevent innovation and force us to waste our
precious time on maintaining legacy stuff. See also [1].
In general, the workflow I use:
Try to build the package with latest dependency version;
if (there are compilation or other problems) {
Check latest upstream development branch;
if (upstream already migrated to later dep version) {
Backport upstream patch and include in the spec;
} else {
try {
Port package to newer dep version;
Include patch in spec file;
Forward patch upstream;
} catch (porting not feasible) {
Ask upstream about updating to new dep version;
Give them some time to react;
if (upstream not responding || package is needed urgently) {
Use compat package as dependency;
Periodically check upstream status of dependency;
Try to remove dep on compat package as soon as it is possible;
}
}
}
}
Sorry for pseudo-code, I hope that this is readable :)
If after reading the above you really want to use compat package, then
indeed you need to use exact dependency version. Better version matching
for compat packages has been on my todo [2] for long time, but as you
probably noticed, compat packages are not top priority for me :)
> 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.
Assuming that the goal is to eventually contribute these packages to
Fedora, I would advice to focus on rawhide only for development. Once
rawhide package is done you can consider porting it to older Fedora (or
EPEL) versions.
You don't need to install rawhide to target it. If used correctly, mock
tool can be very useful in building rawhide packages on other systems.
[1]
https://lists.fedoraproject.org/pipermail/java-devel/2013-October/005000.html
[2] https://github.com/mizdebsk/xmvn/blob/master/TODO#L50-L51
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
Spotify Free Software ombudsman. I/O Tribe.
-- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
