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: [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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
