On 04/07/07, Mark Hobson <[EMAIL PROTECTED]> wrote:
On 21/06/07, Mark Hobson <[EMAIL PROTECTED]> wrote:
> On 21/06/07, Brett Porter <[EMAIL PROTECTED]> wrote:
> > IT doesn't quite sound right - I would have expected it still select
> > nearest and apply the alternate scope from my recollection. But IIRC
> > behaviour was changed ~2.0.4 in relation to scopes, for some
> > particular reason and perhaps this is it: Carlos?
>
> That's what I would have thought too. Anyone have any insight into this?
Ping..?
I'd appreciate if someone could take a look at this problem, which is
summarised in the commented-out test
testProjectWithConflictDependencyScope in:
http://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tree/src/test/java/org/apache/maven/shared/dependency/tree/DependencyTreeBuilderTest.java
The test builds the following project hierarchy:
g:p:t:1
g:a:t:1
g:c:t:1:test
g:b:t:1
g:c:t:1:compile
Which I would expect to be resolved as follows (the commented out
expectation within the test), i.e. nearest-wins:
g:p:t:1
g:a:t:1
g:c:t:1:compile (scope updated from test)
g:b:t:1
(g:c:t:1:compile - omitted for duplicate)
Although Maven fires resolution events that construct the tree as follows:
g:p:t:1
g:a:t:1
(g:c:t:1:compile - scope updated from test; omitted for duplicate)
g:b:t:1
g:c:t:1:compile
Thus the farthest node is selected in the case of an updated scope.
Not only this, but if I change this to be the expected tree (the
uncommented expectation block in the test), then the test fails since
it conflicts with Maven's internal resolution tree, which is:
g:p:t:1 (0; enabled)
g:a:t:1 (1; enabled)
g:c:t:1:compile (2; enabled)
g:b:t:1 (2; enabled)
g:c:t:1:compile (3; disabled)
i.e. the nearest node now wins.
Can anyone shed any light on this?
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
