ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc De Boeck <mdeb...@gmail.com>
Subject Re: How to deal with several "provided" artifacts from different frameworks
Date Mon, 13 Jan 2014 21:18:31 GMT
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 <dk068x@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.
>

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