ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Dockter <>
Subject Re: Filtering optional dependencies of a pom module
Date Wed, 16 Jan 2008 13:04:02 GMT
Hi Xavier,

On Jan 15, 2008, at 7:00 PM, Xavier Hanin wrote:

> On Jan 15, 2008 5:39 PM, Hans Dockter <> wrote:
>> On Jan 7, 2008, at 2:01 PM, Xavier Hanin wrote:
>>> On Jan 5, 2008 7:59 PM, Hans Dockter <> 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. 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. And wouldn't it be funny, if  
Ivy were much more capable to deal with Maven metadata, than Maven  
itself :)

- Hans

View raw message