ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: Multiple release "streams" for different JDK's?
Date Thu, 02 May 2013 15:43:09 GMT
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 <zbedell@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
>
>

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