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 14:14:54 GMT
Hi Xavier,

On Jan 16, 2008, at 2:29 PM, Xavier Hanin wrote:

> On Jan 16, 2008 2:04 PM, Hans Dockter <> wrote:
>> 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  
>>>>> 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  
> 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

View raw message