ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <>
Subject Re: A little more info
Date Wed, 31 Oct 2007 09:23:53 GMT
2007/10/30, Jing Xue <>:
> Quoting Gilles Scokart <>:
> >> -----Original Message-----
> >> From: Richard Suematsu []
> >> Sent: mardi 30 octobre 2007 4:13
> >> To:
> >> Subject: A little more info
> >>
> >> First, should the jar be in there?  Is this just a mistake, or is it
> >> intentional?  I seem to remember the JAI project having native code and
> >> therefore must be installed, but I might be mixing that up with Java
> 3d.
> >>
> >> If the dependency is optional, why does my build break if it can't find
> >> the jar?
> >>
> >
> > You are right.  But I'm not sure Ivy could do something else.
> I don't have a working ivy installation at hand, so I can't try it
> now. But I thought if a dependency is explicitly declared 'optional'
> in pom.xml, the ivy.xml generated would keep it in a separate conf?

It does.  But when you are using the install task (with transitive=true), it
will install the dependencies of all the configuration, including the

Previously, it was not possible to publish only some configurations of the
module, but now it is.  So, I guess we could add a parameter to the install
task to say which configuration to install.

If you need that, you can raise a Jira issue.

At any rate, we usually deal with this kind of situation by taking
> that generated ivy.xml, modifying it with finer conf definitions, and
> putting it in an internal repo so it overrides the original pom.xml.
> For instance, the latest log4j 1.2.15 release added bunch of
> dependencies like jmx and jms, which aren't necessary if you never
> intend to manage logging in a jmx console, or to send logging to a
> message queue. So we have a modified ivy.xml that puts these
> dependencies into separate confs which don't get activated with the
> default dependency mappings.

That's one of the reason for which I think ivy is more flexible than maven

Note that there would be a drawback to have finer 'configuration' on a
shared repository:  Every project would have to document it...  Having just
an 'optional' flag make the thing simpler to produce (and even there,
defining what is optional and what is not is not always easy).


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