Gilles Scokart wrote:
2007/10/30, Jing Xue <[EMAIL PROTECTED]>:
Quoting Gilles Scokart <[EMAIL PROTECTED]>:
-----Original Message-----
From: Richard Suematsu [mailto:[EMAIL PROTECTED]
Sent: mardi 30 octobre 2007 4:13
To: [email protected]
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.
Rich
