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 <[EMAIL PROTECTED]>:
> >> 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 <[EMAIL PROTECTED]> wrote:


-- 
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to