ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Antwort: Multiple release "streams" for different JDK's?
Date Thu, 02 May 2013 15:30:36 GMT
Hi Zac,

if you don't want to change the library names nor the revision number, how 
putting the libs into distinct repositories? Then use different resolver 
chains depending
on which jre version you want to have. 


Von:    Zachary Bedell <>
Datum:  02.05.2013 17:22
Betreff:        Multiple release "streams" for different JDK's?

Greetings all,

We're in the process of migrating our enterprise between Java versions. 
We're at 6 presently and are moving to either 7 or 8, depending on time 
frame, Oracle's release schedule, etc.

We have a number of in-house libraries which we compile and publish to our 
private Ivy repository.  We'll need to compile those libs with the new JDK 
version going forward, but for an extended period of time we'll also need 
to maintain versions compiled with JDK 6 so that our many projects can 
migrate as their schedules permit.  Until we're able to fully retire Java 
6 (likely at least a year), we'll end up with something like the following 
for every build of our libraries:

ourOrg#ourLib;DEV-12345 (JRE 6 version)
ourOrg#ourLib;DEV-12345 (JRE 7 version)

(Where the 12345 is currently the SVN rev the build was created from.)

I'm not sure how best to model the JRE version into Ivy's view of our 
artifacts.  It's not valid to consider the JRE 7 version an "upgrade" to 
the 6 version, so it's not something that would increment or otherwise 
contribute to the version number.  Especially, we wouldn't want projects 
using floating revisions (latest.integration) to switch from one JRE 
version to the other without explicit action taken by the developer.

I'm leery of renaming the modules (ourLib-7) for several reasons.  First, 
I expect the dependency tree would be horribly broken as we have 
interlocking dependencies between our in-house libraries, and changing 
them all recursively would be a nightmare.  Additionally while the -7 case 
is the exception for the time being, it would eventually become the norm, 
and I'd prefer not to have a vestigial -7 stuck on the release names 
forever (or have to undertake a second module name change to remove the 

We're not currently using Ivy's branch tracking feature for anything, and 
I'm curious if this might be an appropriate use case for it.  While 
ultimately the two versions are built of the same source tree (so not a 
branch in the SCM sense), I think it might work for projects desiring the 
JRE-7 builds to apply a branch to their dependency in order to get it.  I 
am still concerned how this will play with the previously mentioned 
interlocking dependencies.  In a case such as:

Project --> lib1(jre7)
       \--> lib2 --> lib1(no-branch)

I'm not sure whether the jre7 branch would "win," whether both branches 
would be pulled in (bad...), or if some combination of force, conflict, 
exclude, etc. would be necessary to get the desired behavior -- namely 
that once a project declares its need for the jre7 branch of a module, 
anything in the entire dependency graph which depends on that module 
should also take only the jre7 branch.

I'd greatly appreciate any guidance on this.

Best regards,
Zac Bedell

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message