I meant that if your project declared a different conflict resolver, then it wouldn't necessarily be used when resolving its dependencies' conflicts.
For example, if Hibernate's pom declared nearest-wins, but your project that depended upon Hibernate declared highest-wins, then nearest-wins would be used to resolve Hibernate's subgraph, the result of which would then be fed into your project's graph for highest-wins resolution. I haven't totally thought this through, but a localised approach to different conflict resolvers would be my gut reaction. Mark 2008/5/28 Brian E. Fox <[EMAIL PROTECTED]>: > How can it not affect transitive dependencies? It is in fact the > transitives that cause the conflicts in the first place. > > -----Original Message----- > From: Mark Hobson [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 28, 2008 10:45 AM > To: Maven Developers List > Subject: Re: dependency version conflict resolution > > 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] > > > --------------------------------------------------------------------- > 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]
