ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: advanced ivy retrieve syntax
Date Thu, 04 Mar 2010 19:42:59 GMT
Juha, suppose you have an mymbeansmodule ivy.xml with the following
<conf name="dev-only" />
<conf name="mbeantypes" />

<artifact name="dev-beans" type="jar" conf="dev-only" />
<artifact name="mbeans" type="jar" conf="mbeantypes" />
<artifact name="dev-only-or-mbeans" type="jar" conf="dev-only,mbeantypes" />

Then in your module that depends on mbeansmodule, you would have a
<dependency org="myorg" name="mymbeansmodule" rev="latest.integration"
conf="default->dev-only+mbeantypes" />

The dev-only+mbeantypes configuration intersection will only get
dev-only-or-mbeans.jar and not the other two jars. Does this work for you?
Note that it requires that the publishing/dependency module be responsible
for saying which artifact gets published when, which is part of the Ivy

Now, what if you want a particular artifact to only be published in an
intersection-like situation? What if you have dev-only-and-mbeans.jar (and
instead of or), and you DON'T want it to be available when the dependent
<dependency org="myorg" name="mymbeansmodule" rev="1.0"
conf="default->dev-only,mbeantypes" />

Note the comma instead of plus: conf="default->dev-only,mbeantypes"

The only way I can think of to accomplish this is to create an extra,
arbitrary pseudo-composite conf:
<conf name="dev-only" />
<conf name="mbeantypes" />
<conf name="dev-only-and-mbeantypes" extends="dev-only,mbeantypes" />

<artifact name="dev-beans" type="jar" conf="dev-only" />
<artifact name="mbeans" type="jar" conf="mbeantypes" />
<artifact name="dev-only-and-mbeans" type="jar"
conf="dev-only-and-mbeantypes" />

Here you're effectively introducing a second filtering parameter, and you
can see how this can get unwieldy fast, especially if you want to use
multiple filters on top of each other. In this respect, I wouldn't mind
seeing a filtering paradigm introduced, but I believe the proper place for
this would be alongside confs rather than on post-resolve tasks like
ivy:retrieve and ivy:cachefileset. It really belongs to the whole resolving
paradigm, where you're presenting an abstraction layer for saying, "Hey,
give me this instead of that, but hide from me the physical artifacts that
are literally involved."

More inline below.

On Thu, Mar 4, 2010 at 10:44 AM, Juha Ranta <> wrote:

> >
> > I've run to a similar need with my confs. The problem seems to arise when
> > I have confs in two or more "dimensions". For instance, while
> constructing
> > my server platform, I need to put some jars in classpath, other jars as
> > Bea shared libraries, others in mbeantypes directory, etc. Fine, I can
> use
> > confs to tell whether I want to put the jar in classpath or the
> mbeantypes
> > directory. However, at the same time, I may need to insert some jars only
> > in the developer's classpath and some only in the runtime classpath.
> >
> > Thus, it would be useful to be able to retrieve, say,
> > "developer+mbeantypes".
> >
> > I looked at the current options in Ivy but didn't find anything that
> > worked well in this situation.
> >
> > Juha Ranta
> >
> Now that I thought of it, I'd like it if I could do something like this:
> <dependency org="xxx" module="dom4j" conf="runtime->default"
> e:localdir="mbeantypes"/>

I'm having a little trouble understanding how you determine what goes in
e:localdir="mbeantypes" and what doesn't if the publishing module (the
dependency) isn't saying so.

> and then use the localdir or whatever extra attribute I defined in the
> dependency in my retrieve task.
> I don't think it's always a good idea to expect that a single jar should
> know whether it is placed in war, ear, APP-INF/lib, classpath, as a BEA
> shared library, in the mbeantypes directory, in the classpath, or whatever,
> and publish all the confs that the user may need.
See, to me, this is the point where it looks like you're keeping Ivy at
arm's length. Why isn't it such a good idea to make the publishing module
dictate via confs what's published when? Is it a matter, as I suggest above,
that the confs can get crazy?

> --
> View this message in context:
> Sent from the ivy-user mailing list archive at

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