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 valid. 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 problem. On Thu, May 2, 2013 at 9:03 AM, Zachary Bedell <zbed...@nycourts.gov> 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 <mgit...@gmail.com> 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. > >
