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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
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]
