It seems to me this is a classic use case for Ivy confs. So your ivy.xml
might specify:
<configurations>
<conf name="package" />
<conf name="java6" extends="package" />
<conf name="java7" extends="package" />
<conf name="java8" extends="package" />
<conf name="default" extends="java6" />
< configurations>
<publications>
<artifact name="application-java6" type="jar" conf="java6" />
<artifact name="application-java7" type="jar" conf="java7" />
<artifact name="application-java8" type="jar" conf="java8" />
</publications>
This way you can have everything in the same Ivy module with the same
version and the same branch in the same repository--because, in fact, all
these conditions are the same for the different artifacts for different
Java versions. Then the dependent modules' ivy.xml files would specify
conf="MY_CONF->java6" in the dependency element. Or better yet,
conf="MY_CONF->default". Note that default extends java6. That way you can
change the standard version of Java consumed with a new version of your
module without making the dependent projects know about it.
On Thu, May 2, 2013 at 8:25 AM, Zachary Bedell <zbed...@nycourts.gov> wrote:
> 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
>
>
