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 iss
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
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]> w
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. B
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 scop
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: Car
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
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 prefe
