On 22-May-08, at 7:28 AM, Paul Gier wrote:
Improved dependency version conflict resolution, and a lot of other
important issues either require or would benefit from changing the
pom model. As far as I can tell, there have not yet been any
changes to this model in the 2.1 branch. So I was wondering what
should be the strategy for changes in the future?
Brian brought up the issue that if we change the model and start
deploying artifacts to the repository that use the new poms, then
there may be some incompatibility if the dependency tree contains a
mix of older and newer poms. So the remaining choices appear to be
either start a new repository or never change the pom model.
So can we make changes to the model in 2.1, or do we have to work
with the existing model?
Provide we retain the behavior of old with a flag if the user desires
with 2.1 the door is wide open to correct anything we see fit.
Mark Hobson wrote:
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
--
In short, man creates for himself a new
