Not much to add other than "I agree". I think maven should take an approach
similar to Ivy. Allow users to choose from some common conflict resolution
strategies, or implement their own if none of the standard ones meet their needs.
Gilles Scokart wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
