Yep, my ongoing saga with conflict resolution is detailed here: http://docs.codehaus.org/display/MAVEN/Conflict+Resolvers http://jira.codehaus.org/browse/MNG-612
Would be great to get this resolved. Mark 2008/5/22 Brett Porter <[EMAIL PROTECTED]>: > That's what I was referring to. > > On 22/05/2008, at 10:25 AM, Brian E. Fox wrote: > >> I thought Mark already started this and/or has a proposal on the wiki. >> >> -----Original Message----- >> From: Brett Porter [mailto:[EMAIL PROTECTED] On Behalf Of Brett >> Porter >> Sent: Wednesday, May 21, 2008 8:11 PM >> To: Maven Developers List >> Subject: Re: dependency version conflict resolution >> >> Hi John, >> >> I don't think there's any objection to implementing this strategy - >> however it's something that needs to be done in a pluggable way so >> that current build behaviour doesn't change. This has a few >> dependencies on other work in the core. >> >> Some people who are interested have contributed towards this in the >> past. Is this something you are looking to work on, or just making a >> request? >> >> Thanks, >> Brett >> >> On 22/05/2008, at 5:36 AM, John Williams wrote: >> >>> I'm new to list list so I apologize if this has been beaten to death >>> before, but I'd like to propose a change to the version conflict >>> resolution strategy that Maven uses. It's a combination of the >>> current "nearest version" strategy and a "highest version" strategy. >>> There are two cases: >>> >>> 1. When an artifact has a declared dependency, the declared version >>> always takes precedence over any inherited version. >>> 2. When a project inherits two versions of the same dependency, the >>> highest-numbered version takes precedence. >>> >>> Rule 1 is consistent with the "nearest" strategy. It is necessary to >>> give developers adequate control over the dependencies they use, and >>> also because it would be very confusing for Maven to use an artifact >>> version other than the one declared in the pom.xml file. I believe >>> this rule preserves all the desirable features of the "nearest" >>> strategy. >>> >>> Rule 2 is consistent with a "highest" strategy, and it addresses the >>> problem of unrelated artifacts overriding each other's dependencies. >>> Suppose artifact A depends on B and C, both of which depend on >>> different versions of D (and A does not depend directly on D). >>> Obviously either B or C will be forced for use a version of D for >>> which it was not designed, but if the developer of D has made some >>> attempt to preserve compatibility across versions, the higher-numbered >>> version of D is far more likely to work with both B and C and the >>> lower-numbered version. I think this would be a big improvement over >>> the somewhat arbitrary decision that the "nearest" strategy would >>> make. >>> >>> --jw >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >> >> -- >> Brett Porter >> [EMAIL PROTECTED] >> http://blogs.exist.com/bporter/ >> >> >> --------------------------------------------------------------------- >> 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] >> > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > --------------------------------------------------------------------- > 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]
