Ideally conflict resolvers would be local to a project, so that they wouldn't have an impact on transitive dependencies. This would be something for the maven-artifact graph-based rewrite, I certainly wouldn't like to patch the current event-based version to achieve this!
Mark 2008/5/28 Brian E. Fox <[EMAIL PROTECTED]>: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
