You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mark Hobson <ma...@gmail.com> on 2007/07/04 16:29:02 UTC
Re: More DefaultArtifactCollector queries
On 21/06/07, Mark Hobson <ma...@gmail.com> wrote:
> On 21/06/07, Brett Porter <br...@apache.org> 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..?
This is appearing to prevent a solution to the artifact filtering
problem detailed in "Artifact filtering in DefaultArtifactCollector",
since filtering listener events causes only DACT.testScopeUpdate to
fail.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: More DefaultArtifactCollector queries
Posted by Mark Hobson <ma...@gmail.com>.
Okay, a bit of closure on this thread..
The apparent conflict with the internal resolution tree was due to
incorrect assertions by the test - the artifacts were being collected
twice, and since collection mutates artifacts, an incorrect resolution
tree was being produced. Now fixed.
The main issue of a farthest artifact winning over a nearest one still
seems slightly wrong to me. It appears to have been introduced by the
fix for MNG-1895. A quick example is as follows: The following
dependency tree:
g:p:t:1
\- g:a:t:1
+- g:b:t:1
| \- g:c:t:1:compile
\- g:c:t:1:test
Gets resolved as:
g:p:t:1
\- g:a:t:1
+- g:b:t:1
| \- g:c:t:1:compile
\- (g:c:t:1:compile - scope updated from test; omitted for duplicate)
Whereas I would have thought nearest should still win:
g:p:t:1
\- g:a:t:1
+- g:b:t:1
| \- (g:c:t:1:compile - omitted for duplicate)
\- g:c:t:1:compile (scope updated from test)
I don't think fixing this would fail the test for MNG-1895, since it
only considers the resolved set of artifacts. Also, I think that
using nearest wins here would also fix MNG-3089, which is currently
blocking filtering a dependency tree by scope.
Any comments?
Cheers,
Mark
On 25/09/2007, Mark Hobson <ma...@gmail.com> wrote:
> On 24/07/2007, Brett Porter <br...@apache.org> wrote:
> > IIRC, it switched to the other dependency because the alternate scope
> > is going to modify the subtree under that dependency. Does that make
> > sense?
>
> Blast from the past.. sorry Brett, I don't see what your saying here.
> There's no subtree under the conflicting dependency (g:c:t:1) to be
> modified. And why would the fired events differ from the resolution
> tree as described above?
>
> Cheers,
>
> Mark
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: More DefaultArtifactCollector queries
Posted by Mark Hobson <ma...@gmail.com>.
On 24/07/2007, Brett Porter <br...@apache.org> wrote:
> IIRC, it switched to the other dependency because the alternate scope
> is going to modify the subtree under that dependency. Does that make
> sense?
Blast from the past.. sorry Brett, I don't see what your saying here.
There's no subtree under the conflicting dependency (g:c:t:1) to be
modified. And why would the fired events differ from the resolution
tree as described above?
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: More DefaultArtifactCollector queries
Posted by Brett Porter <br...@apache.org>.
IIRC, it switched to the other dependency because the alternate scope
is going to modify the subtree under that dependency. Does that make
sense?
On 14/07/2007, at 2:18 AM, Mark Hobson wrote:
> On 04/07/07, Mark Hobson <ma...@gmail.com> wrote:
>> On 21/06/07, Mark Hobson <ma...@gmail.com> wrote:
>> > On 21/06/07, Brett Porter <br...@apache.org> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: More DefaultArtifactCollector queries
Posted by Mark Hobson <ma...@gmail.com>.
On 04/07/07, Mark Hobson <ma...@gmail.com> wrote:
> On 21/06/07, Mark Hobson <ma...@gmail.com> wrote:
> > On 21/06/07, Brett Porter <br...@apache.org> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org