ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Suematsu <>
Subject Re: A little more info
Date Thu, 01 Nov 2007 22:32:12 GMT
Gilles Scokart wrote:
> 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
> optionals.
> 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).
> Gilles
I don't know much about maven, but I'm starting to see the flexibility 
of Ivy.  I just got to the part in my project that includes Spring.  In 
our previous build process, I just included the full Spring jar and 
whatever else I needed for the part I was using.  No problem.

So switching to Ivy, I grab from the maven repo the full Spring 2.0 
jar.  Bad. It included about 40 dependencies include stuff that isn't in 
the repo like the Oracle jars.  So I started looking into the Ivy file 
to redefine how its set up, but I stopped. The real answer, of course, 
is to only use the parts of Spring I need.

Dealing with the maven repo has been the most frustrating part of this 
process.  I sure a large part of it is that I wasn't a maven user 
before.  It conceptually works different than our current build process, 
but I getting past the learning curve and am starting to like it.

I understand there used to be an ivyrepo before that, I assume, tried to 
clean up a few things like having apache  | commons-lang instead of 
commons-lang | commons-lang.  I also assume it got taken down when Ivy 
became an official Apache project and because its probably too much to 
ask of these projects to maintain 2 dependency definitions.  But I also 
imagine each of us (ivy users) will be recreating some work when 
creating our own repositories from the maven repository.


View raw message