ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: Multiple release "streams" for different JDK's?
Date Thu, 02 May 2013 17:08:40 GMT
Since you hadn't mentioned confs, I was making the assumption that you
weren't using confs. Good to see you are.

I think your criticisms of using confs for this in your situation are

And I think Carsten's suggestion of multiple repos is workable and
preferable to confs. As long as clients want to control which JDK they're
using, they can choose which repo to use. This would also work nicely with
a CI server. Then you'd have one job for Java 6, one for Java 7, one for
Java 8.

>From my standpoint, one problem with using repos for this is that it leads
to repo proliferation and forces consumers to worry about one more thing in
their Ivy settings, but I can understand one could live with this. My
bigger problem is that it's not literally "correct," in the sense of
orthodox dependency management. For a given org+module+revision
combination, there should be just one unique set of artifacts. But I can
understand how that's something you can live with as well, and certainly
Ivy lets you get away with it.

Now that I think about it some more, if I were tackling this problem, I'd
go with different Ivy modules, one for each JDK version. And then I'd have
a "default" Ivy module be a particular JDK version Ivy module. This would
fit just as nicely with multiple jobs on a CI server. At the time you're
ready to make the switch from defaulting to Java 6 to Java 7, you'd do that
with a new version of the default module. So you'd be announcing to
consumers that, if you're using version 2.0.x of the default module, then
you're getting the Java 7 support. For consumers, this is part of the
bargain of consciously upgrading dependency versions. This is part of the
value of versioning.

Again, more "correct," but probably less seamless for your particular

On Thu, May 2, 2013 at 9:03 AM, Zachary Bedell <> wrote:

> Thanks for the suggestion, but there are two problems that break this for
> us I think.
> First, we already use several configurations in many of the libraries in
> order to separate distinct dependency groups (which ideally should be
> refactored to separate libraries, but...).  For example, we have
> configurations such as gui, server, and webservices which allow sub-setting
> the runtime dependencies depending on the client project's needs.  We also
> use this for separating appserver versus client depends like:
> conf="build->build; client->gui; server->server,webservices"
> Second, I think it's safer to build the JRE 6 & JRE 7 configurations in
> completely separate processes and have the target JRE passed in as an
> attribute to the build environment.  I'd be concerned about attributes of
> the different JRE's "leaking" if the build had to be run twice in one pass.
>  As the build stands now, we'd end up with only one half of the required
> artifacts.  The artifacts for the "other" JRE wouldn't be available to
> publish.  I'd prefer not to make changes to the build process to build &
> package two completely separate artifact sets.  Ideally running Ant with
> the appropriate JAVA_HOME and PATH set, plus maybe a -D of some sort to
> indicate the publication destination.
> Thanks again,
> Zac
> On May 2, 2013, at 11:43 AM, Mitch Gitman <> wrote:
> > 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.

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