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/18 19:02:29 UTC
DefaultArtifactCollector event change
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 DefaultArtifactCollector.fireEvent for OMIT_FOR_NEARER,
the event is only fired to listeners if the versions differ. Hence
the event is never fired for duplicate nodes, which makes it
impossible to accurately reflect what Maven is doing internally in the
dependency tree. I'd like to remove this restriction to allow
interested listeners to easily track duplicates.
Has anyone got objections to me committing this change to 2.0.x and 2.1?
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DefaultArtifactCollector event change
Posted by Mark Hobson <ma...@gmail.com>.
On 18/06/07, Jason van Zyl <ja...@maven.org> 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 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 much
> of the structure there gets wiped out in 2.1.
Yep, I figured this would be happening in 2.1. I'm currently
targeting 2.0.x but am interested in any work moving this forward.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DefaultArtifactCollector event change
Posted by Brett Porter <br...@apache.org>.
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.
However, I'm glad to take a look at how it works. We should
definitely have the spec in hand as we look at the alternatives.
- Brett
On 20/06/2007, at 1:38 AM, Kenney Westerhof wrote:
> 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 metadata before the artifacts are materialized so don't
>>>> be overly surprised if much of the structure there gets wiped
>>>> out in 2.1.
>>>>
>>> You and I discussed this before. Has any of the code been written
>>> to do this? While I have to agree that not creating the graph
>>> before processing has fundamental problems, I'm also concerned
>>> about what kind of performance impact this might have.
>>>
>>
>> I do, but as I told brett (who also asked) what I have is an
>> implementation that is agnostic to policy. What that means is that
>> the spec is required and we need to work on that first. I'm just
>> swamped with client work, the release and generally trying to
>> clean up the wiki and jira but i'll make an attempt this weekend
>> to drop some code.
>>
> That's cool, that it's agnostic to policy, That way we can apply
> the policy afterwards and show what the policy in effect does.
> We can also have a mojo apply several policies, producing several
> output graphs/trees to illustrate the differences,
> or we can split off the policies into smaller pieces so we can
> sequentially apply them - one for scope filtering, one for depMgt
> application, one for transitive deps maybe, one for snapshot
> handling, one for including optional dependencies based on code
> requirements (maybe), one for conflict resolution (latest/oldest
> for 2 nodes at the same depth). We can even flatten the structure
> so that we only have 1 version of a dep left in the module
> hierarchy in the reactor, or let each module use whatever version
> their
> subscope tells them to use (so versions can differ per module).
>
> I think having something policy-agnostic and filtering it out later
> is the best way to go - divide and conquer. So what you have
> doesn't necesarily need the spec applied to - we may just need to
> add another processing step after it that implements the spec.
> Whenever
> we change/improve the spec, it'll be an easy adjustment since it's
> not hardcoded in the dep resoluion, and we can simply apply
> different strategies for different versions of the poms/maven
> versions.
>
> -- Kenney
>>> Ralph
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder and PMC Chair, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DefaultArtifactCollector event change
Posted by Kenney Westerhof <fo...@neonics.com>.
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
>>> metadata before the artifacts are materialized so don't be overly
>>> surprised if much of the structure there gets wiped out in 2.1.
>>>
>> You and I discussed this before. Has any of the code been written to
>> do this? While I have to agree that not creating the graph before
>> processing has fundamental problems, I'm also concerned about what
>> kind of performance impact this might have.
>>
>
> I do, but as I told brett (who also asked) what I have is an
> implementation that is agnostic to policy. What that means is that the
> spec is required and we need to work on that first. I'm just swamped
> with client work, the release and generally trying to clean up the
> wiki and jira but i'll make an attempt this weekend to drop some code.
>
That's cool, that it's agnostic to policy, That way we can apply the
policy afterwards and show what the policy in effect does.
We can also have a mojo apply several policies, producing several output
graphs/trees to illustrate the differences,
or we can split off the policies into smaller pieces so we can
sequentially apply them - one for scope filtering, one for depMgt
application, one for transitive deps maybe, one for snapshot handling,
one for including optional dependencies based on code requirements
(maybe), one for conflict resolution (latest/oldest for 2 nodes at the
same depth). We can even flatten the structure
so that we only have 1 version of a dep left in the module hierarchy in
the reactor, or let each module use whatever version their
subscope tells them to use (so versions can differ per module).
I think having something policy-agnostic and filtering it out later is
the best way to go - divide and conquer. So what you have doesn't
necesarily need the spec applied to - we may just need to add another
processing step after it that implements the spec. Whenever
we change/improve the spec, it'll be an easy adjustment since it's not
hardcoded in the dep resoluion, and we can simply apply
different strategies for different versions of the poms/maven versions.
-- Kenney
>> Ralph
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> 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: DefaultArtifactCollector event change
Posted by Jason van Zyl <ja...@maven.org>.
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 artifacts are materialized so don't be overly
>> surprised if much of the structure there gets wiped out in 2.1.
>>
> You and I discussed this before. Has any of the code been written
> to do this? While I have to agree that not creating the graph
> before processing has fundamental problems, I'm also concerned
> about what kind of performance impact this might have.
>
I do, but as I told brett (who also asked) what I have is an
implementation that is agnostic to policy. What that means is that
the spec is required and we need to work on that first. I'm just
swamped with client work, the release and generally trying to clean
up the wiki and jira but i'll make an attempt this weekend to drop
some code.
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DefaultArtifactCollector event change
Posted by Ralph Goers <Ra...@dslextreme.com>.
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 much of
> the structure there gets wiped out in 2.1.
>
You and I discussed this before. Has any of the code been written to do
this? While I have to agree that not creating the graph before
processing has fundamental problems, I'm also concerned about what kind
of performance impact this might have.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DefaultArtifactCollector event change
Posted by Jason van Zyl <ja...@maven.org>.
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 identical versions, i.e. they are duplicate nodes.
>
> You can see in DefaultArtifactCollector.fireEvent for OMIT_FOR_NEARER,
> the event is only fired to listeners if the versions differ. Hence
> the event is never fired for duplicate nodes, which makes it
> impossible to accurately reflect what Maven is doing internally in the
> dependency tree. I'd like to remove this restriction to allow
> interested listeners to easily track duplicates.
>
> Has anyone got objections to me committing this change to 2.0.x and
> 2.1?
>
As long as you run all the ITs and make sure they work before
committing. Running the unit tests is not enough unfortunately.
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 much
of the structure there gets wiped out in 2.1.
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org