To group a number of artifacts together, we sometimes define a virtual component which contains all the dependencies for such framework. A virtual component in our terminology, has an ivy.xml file containing the required dependencies, but does not contain any publications (you must specify explicitly specify an empty publications element otherwise Ivy will assume you want to publish a jar-file).
You can use ivy-configuration to implement the "provided" (and other scopes) from maven: you can define a configuration "compile" that contains all the dependencies you need for compiling your project, and a configuration "runtime" containing the dependencies that need to go in your runtime package. During the compilation, you do a resolve (possibly with a retrieve) of the "compile" configuration. And when assembling your deployable component, you do a resolve of your "runtime" configuration. Ivy-configurations provide imo more possibilities compared to Maven-scope, but you need to invest some time in learning how to use them properly. Regards, Marc 2014/1/13 KARR, DAVID <dk0...@att.com> > I'm continuing to look at the large multi-module Ant build I work with, to > see if I could clean this up a bit by integrating Ivy. > > I'm not just looking at how to clean up the build, but to make it easier > for developers to work with checked-out projects in Eclipse. > > Besides the somewhat haphazard way we reference simple third-party and > internal artifacts (all of which I see how I can Ivy-ize), we also use two > large frameworks that encompass several jars each, and both of those jar > sets are "provided" artifacts, like the use of "provided" artifacts in > Maven, where we want to make them available at compile time, but those > artifacts are not to be assembled into the deployable component, as they > will be available at runtime, however the framework does it. > > Presently, these "provided" frameworks are specified in our Eclipse > projects as "variables", but this is messy. > > If I end up specifying these numerous jars in ivy dependencies, it would > be nice if I could group them, so it's clear what list of jars is part of > framework "foo", and which is part of framework "bar". You could do this > with Maven by specifying a pom that just lists those artifacts, and having > projects reference that pom. >
