ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Dockter <m...@dockter.biz>
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 <mail@dockter.biz> wrote:
>
>> Hi Xavier,
>>
>> On Jan 15, 2008, at 7:00 PM, Xavier Hanin wrote:
>>
>>> On Jan 15, 2008 5:39 PM, Hans Dockter <mail@dockter.biz> wrote:
>>>
>>>>
>>>> On Jan 7, 2008, at 2:01 PM, Xavier Hanin wrote:
>>>>
>>>>> On Jan 5, 2008 7:59 PM, Hans Dockter <mail@dockter.biz> 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


Mime
View raw message