Hi Xavier,
On Jan 16, 2008, at 2:29 PM, Xavier Hanin wrote:
On Jan 16, 2008 2:04 PM, Hans Dockter <[EMAIL PROTECTED]> wrote:
Hi Xavier,
On Jan 15, 2008, at 7:00 PM, Xavier Hanin wrote:
On Jan 15, 2008 5:39 PM, Hans Dockter <[EMAIL PROTECTED]> wrote:
On Jan 7, 2008, at 2:01 PM, Xavier Hanin wrote:
On Jan 5, 2008 7:59 PM, Hans Dockter <[EMAIL PROTECTED]> wrote:
I have the following probably pretty common use case. It is an
issue
related to maven pom's.
Let's say I declare a dependency on the groovy-all module. The
groovy-
all pom declares 9 optional dependencies. I need one of of the
optional dependencies for my usage scenario of groovy-all. If
you are
a Maven2 users there is no good way of dealing with this
situation.
What you have to do, is to declare the optional dependency you
want
as a first level dependency in your pom. How can I deal with
this in
Ivy? The module descriptor created out of the pom, has two
configurations I'm interested in. This is default (Maven's
compile
and runtime scope) and optional (all dependencies declared
optional
in the pom). Now I can do the following:
<dependency org="org.codehaus.groovy" name="groovy-all"
rev="1.5.1"
conf="compile->default,optional"/>
This add all 9 optional dependencies to the compile
configuration.
But I want only one. As I understand Ivy, I can only apply
exclude
and include filtering to the master configuration. In this case
that
would mean I have to add 8 exclude statements to exclude the
unwanted
optional dependencies. Alternatively I could declare include
statements for all the required dependencies. Both is pretty
impractical. I would like to declare filters on the dependency
configuration, to say something like: include MODULE_X of
OPTIONAL
How is this different from the use of the include element when
declaring the
dependency?
Xavier
I think there has been a misunderstanding on my side regarding the
include element. I have missed the fact that In contrast to the
exclude element, include does not apply to the dependencies of a
dependency, but only to published artifacts of the dependency,
right?
Right.
What I have in mind is an include for (first level) dependencies
of a
dependency. I'm not sure if this is a good idea. I'm just
looking for
a good solution for the use case described above.
What could be done is make the include mechanism work for transitive
dependencies, as the exclude mechanism does (but it used to work as
include,
only on artifacts from the direct dependency). But limiting this
to first
level dependencies is even another feature, I see the use case, but
it makes
things even more complex to handle and understand. When metadata
need so
much tweaking, I guess you should better rewrite the metadata, or
define a
new virtual module with fixed metadata.
I see your point. And for any enterprise environment what you propose
is definitely the way to go.
Yet I think almost any project, even simple ones, should have
dependency management.
Agreed.
For the developers of those simple projects,
creating there own repository might seem pretty heavy weight. For
those simple projects, sharp tools to manipulate the metadata on the
client side would be often quite handy.
Indeed, that's why we already have stuff like the existing
exclude/include/artifact mechanisms, and the transitive attribute.
And wouldn't it be funny, if
Ivy were much more capable to deal with Maven metadata, than Maven
itself :)
I think it's already the case. Try to disable transitivity for a
dependency,
or exclude a set of transitive dependencies using a regular
expression, or
redefine the set of artifacts published by a module, including with
the URL
where the artifact is located... none of this is possible in maven
AFAIK,
and I don't even talk about the flexibility offered by configuration
mapping.
I completely agree. This is very cool stuff not offered by Maven.
Thanks for all your help.
- Hans
