You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Paul Gier <pg...@redhat.com> on 2008/06/04 04:51:11 UTC

Re: dependency version conflict resolution

Sorry Gilles, I didn't mean to try put words in your mouth :)  I probably just 
read your email describing Ivy too quickly and assumed that you wanted Maven to 
have similar features.

Gilles Scokart wrote:
> For the record, note that I didn't argue that maven should do the same
> than ivy.  Ivy has a general philosophy of flexibility.  Maven has a
> philosophy of promoting good practices.
> 
> I guess that both should be consistent with their general pholosophy...
> 
> But I didn't answered to the question "Is it a good practice to adapt
> your conflict manager in function of your context ?".
> 
> 
> 2008/5/28 Michael McCallum <gh...@apache.org>:
>> I concur with John,
>>
>> The key problem with plugable conflict resolution is that in my case I use
>> hundreds of open source artifacts that all have interdepdencies that work
>> based on the current maven conflict resolution model...
>>
>> If you make it pluggable where do you start and end with any strategy, how do
>> you get a consistent and understandable resolution.
>>
>> One "good" library to bring up would be commons-logging, it ubiquitous many
>> things depend on it. I exclude it because I prefer to use slf4j. If libraries
>> I use have there own strategy could they then override my exclusion or force
>> the tree to resolve such that my exclusions are in the wrong place.
>>
>> To me its like saying people should drive on any side of the road, depending
>> on whats best for them. We don't do that we all drive on the same side of the
>> road in any given country so that we can use the road "safely" with other
>> users in a consistent manner.
>>
>>>> 2008/5/28 John Williams <jr...@pobox.com>:
>>>>> Brett,
>>>>>
>>>>> I'd be happy to work on implementing it, but I'm wary of the idea of
>>>>> pluggable strategies for something as fundamental as version conflict
>>>>> resolution.  I agree that any new behavior needs to be switched on
>>>>> with a flag in the pom file in order to avoid breaking legacy builds,
>>>>> but beyond that I don't see much value in letting the user select a
>>>>> strategy.  When is an alternate strategy appropriate, and how is a
>>>>> user supposed to make that decision?  The sad fact is that pom files
>>>>> don't provide enough information to reliably resolve conflicting
>>>>> versions or detect when no resolution is possible.  Any strategy is
>>>>> just a heuristic that will be wrong in some cases, so IMHO it's better
>>>>> to have a single strategy that's easy to understand and override when
>>>>> necessary than to have multiple strategies that all fail in different
>>>>> ways.
>>>>>
>>>>> jw
>>>>>
>>>>> On Wed, May 21, 2008 at 7:11 PM, Brett Porter <br...@apache.org> wrote:
>>
>> --
>> Michael McCallum
>> Enterprise Engineer
>> mailto:gholam@apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org