Re: More DefaultArtifactCollector queries
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 <[EMAIL PROTECTED]> wrote: > On 24/07/2007, Brett Porter <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More DefaultArtifactCollector queries
On 24/07/2007, Brett Porter <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More DefaultArtifactCollector queries
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 <[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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More DefaultArtifactCollector queries
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]
Re: More DefaultArtifactCollector queries
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..? 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More DefaultArtifactCollector queries
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? 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More DefaultArtifactCollector queries
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
