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]