My concern is the same, but I'll take it a step further. Custom conflict resolution strategies reduce the overall ability to jump in and understand any Maven build.
-----Original Message----- From: Michael McCallum [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2008 9:45 AM To: Maven Developers List Subject: Re: dependency version conflict resolution 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
