I agree.
I likewise share concerns about the performance of this. My
preference would be for the policy to be better separated, but still
applied during the resolution process. In my mind this had always
been the place for 'conflict resolvers' to enforce policy during the
process.
Howev
Jason van Zyl wrote:
On 18 Jun 07, at 10:43 PM 18 Jun 07, Ralph Goers wrote:
Jason van Zyl wrote:
And I'm still trying to get all the "getting prepared for 2.1"
before I start fleshing out any specs. But the artifact resolution
in 2.0.x is fundamentally wrong in not making a graph of the
On 18/06/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
As long as you run all the ITs and make sure they work before
committing. Running the unit tests is not enough unfortunately.
Sure, will do thanks.
And I'm still trying to get all the "getting prepared for 2.1" before
I start fleshing out
On 18 Jun 07, at 10:43 PM 18 Jun 07, Ralph Goers wrote:
Jason van Zyl wrote:
And I'm still trying to get all the "getting prepared for 2.1"
before I start fleshing out any specs. But the artifact resolution
in 2.0.x is fundamentally wrong in not making a graph of the
metadata before the
Jason van Zyl wrote:
And I'm still trying to get all the "getting prepared for 2.1" before
I start fleshing out any specs. But the artifact resolution in 2.0.x
is fundamentally wrong in not making a graph of the metadata before
the artifacts are materialized so don't be overly surprised if mu
On 18 Jun 07, at 10:02 AM 18 Jun 07, Mark Hobson wrote:
Hi there,
I'm working on adding omitted nodes support to dependency-tree and
have come across a limitation within DefaultArtifactCollector. The
problem is when one node is omitted for conflicting with a nearer node
and they have identica
Hi there,
I'm working on adding omitted nodes support to dependency-tree and
have come across a limitation within DefaultArtifactCollector. The
problem is when one node is omitted for conflicting with a nearer node
and they have identical versions, i.e. they are duplicate nodes.
You can see in
