ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zachary Bedell <zbed...@nycourts.gov>
Subject Multiple release "streams" for different JDK's?
Date Thu, 02 May 2013 15:25:19 GMT
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 -7).

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


Mime
View raw message