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/06/20 18:37:19 UTC
More DefaultArtifactCollector queries
Hi there,
I've having problems with DefaultArtifactCollector events when scopes
are being updated. The scenario in question is as follows:
p -> a
a -> c:test, b
b -> c:compile
This resolves as follows:
1) c:test's scope is broadened to compile
2) p -> a -> c:test is disabled in preference to p -> a -> b -> c:compile
Firstly: (1) I understand; (2) why is the farthest node chosen over
the nearest? Does updating the scope logically mean that the normal
nearest-wins conflict resolution is simply reversed? From what
digging I've done, I assume this is to do with MNG-1895, but I can't
see any mention of this behaviour in the "Dependency Mediation and
Conflict Resolution" wiki page. Can anyone expand on this?
Secondly: Assuming the above behaviour is correct, should the
OMIT_FOR_NEARER event fired in line 232 of DAC not reflect this
swapping over of nodes? Currently, if the scope is updated then the
nearest node is disabled, otherwise the farthest node is disabled; but
in *both* situations the OMIT_FOR_NEARER event is fired with the
farthest node being replaced by the nearest. This sounds wrong to me.
Any insights welcome,
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
Re: More DefaultArtifactCollector queries
Posted by Mark Hobson <ma...@gmail.com>.
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>.
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?
> Second part sounds like a simple oversight.
Cool, I've committed a fix to both 2.0.x and trunk.
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>.
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?
Second part sounds like a simple oversight.
- Brett
On 21/06/2007, at 2:37 AM, Mark Hobson wrote:
> Hi there,
>
> I've having problems with DefaultArtifactCollector events when scopes
> are being updated. The scenario in question is as follows:
>
> p -> a
> a -> c:test, b
> b -> c:compile
>
> This resolves as follows:
>
> 1) c:test's scope is broadened to compile
> 2) p -> a -> c:test is disabled in preference to p -> a -> b ->
> c:compile
>
> Firstly: (1) I understand; (2) why is the farthest node chosen over
> the nearest? Does updating the scope logically mean that the normal
> nearest-wins conflict resolution is simply reversed? From what
> digging I've done, I assume this is to do with MNG-1895, but I can't
> see any mention of this behaviour in the "Dependency Mediation and
> Conflict Resolution" wiki page. Can anyone expand on this?
>
> Secondly: Assuming the above behaviour is correct, should the
> OMIT_FOR_NEARER event fired in line 232 of DAC not reflect this
> swapping over of nodes? Currently, if the scope is updated then the
> nearest node is disabled, otherwise the farthest node is disabled; but
> in *both* situations the OMIT_FOR_NEARER event is fired with the
> farthest node being replaced by the nearest. This sounds wrong to me.
>
> Any insights welcome,
>
> 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