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
