On 23 Apr 07, at 1:01 PM 23 Apr 07, Mark Hobson wrote:
Hi there,
I've had an initial stab at implementing ConflictResolvers and
attached a patch to MNG-612. If people wouldn't mind taking a peek,
I'd appreciate some feedback on the following:
Not sure if you noticed the MNG-1577 debate, but much of the conflict
resolution has been solved by the specification of the versions in
depMan ruling out over anything. Now the cases where you are pulling
in a transitive dependency that can come from two, or more, distinct
subgraphs that you have not defined in your depMan is where some form
of conflict resolution might come into play. I think for the most
part people would want to be able to see this transitive graph and
select the version, until such a time that we can say definitively
that the latest version of something is compatible with everything
else being used. I think we are quite a ways away from that people
would probably end up locking down a version in depMan.
But ultimately what is currently there must be replaced by a system
that does not alter the graph while the graph is forming. By this I
mean the entire graph must be resolved first and any subsequent
transformation whether that be scope state changes, version
alignment, and repository ordering must be done using standard graph
transformation.
We simply need a resolution specification and it has to be based on a
graph being the fundamental unit of work. There is far too much
transformation going on mid stream and it causes problems, and we
lose critical information that would make deterministic choices hard
if not impossible right now. It will be one of the things I will be
bring up at ApacheCon and JavaOne. It is the source of greatest
bewilderment to users, especially the behavior prior to MNG-1577.
So I would be hesitant to apply any of these changes to trunk.
Jason.
1) ConflictResolver API - is the negative/positive/zero return type
sufficient, or would a boolean return type with an exception for the
unresolvable state be more appropriate?
2) ArtifactCollector signature change - is this okay or will it break
lots of code? If we are to maintain the original signatures, then
should we really obtain a default ConflictResolver implementation via
plexus?
3) New ArtifactResolver overloaded method okay? The original method
implementations in DefaultArtifactResolver assume plexus default - is
this okay or should it be passed in?
4) DefaultArtifactCollectorTest - many tests assume nearest conflict
resolver, should these be refactored out?
5) ResolutionListener.OMIT_FOR_NEARER - should this be refactored to
OMIT_FOR_CONFLICT?
6) Configuration - how do we specify a different conflict resolver
implementation for the build? This does overlap with MNG-2771, but do
we want a friendlier POM configuration based on role hints? e.g.
<build><conflictResolver>newest</conflictResolver></build>. Does
specifying an alternative conflict resolver in Maven's components.xml
potentially cause problems outside of the build and within Maven
itself?
7) Conflict resolver implementation names - newest/oldest or
highest/lowest?
8) Any more conflict resolver implementations required?
I've got some time allocated to work on this, so any thoughts are
welcome and hopefully we can get this much-needed functionality into
Maven.
Cheers,
Mark
---------------------------------------------------------------------
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]
