There are actually plenty of conflict resolution strategy. Every users may preffer its own style based on the characteristics of its project, depending on what level of control he want to have versus the effort he want to give, depending of the size of its project, depending on the typical release cycle used in its organisation, etc.
Some people consider a conflict is not acceptable, and should broke the build. Other want some very clear warning that can be manually checked when conflict is detected and resolved, others doesn't care and just rely on the test to check everything is ok. In Ivy, we are giving the possibility to plug different conflict managers [1]. In ivy, that fit with the overall philosiphy that we want to give the maximum flexibility to the user. [1] http://ant.apache.org/ivy/history/latest-milestone/configuration/conflict-managers.html 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: >> 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] > > -- Gilles Scokart --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
