On 29/06/2007, at 2:35 AM, Mark Hobson wrote:
On 28/06/07, Brett Porter <[EMAIL PROTECTED]> wrote:
The gross thing the wagon manager does for the proxy, etc is to push
the settings in from the core to the wagon manager itself so there's
passing it through the api.
Otherwise, I guess you'll need to pass the conflict resolver property
through the artifact resolver api as well to get the details from the
core into the artifact handling, and then do the lookup in the
collector.
Okay, I've committed my work so far on this issue to the MNG-612
branch, which is branched from 2.0.x:
http://svn.apache.org/repos/asf/maven/components/branches/MNG-612/
If anyone has a few mins to glance over the diff then any feedback
would be appreciated.
Will do.
As discussed with Brett, I went for a POM property to control the
conflict resolvers: 'maven.conflict.resolvers'. This property has a
comma-separated value of role hints to use for the list of conflict
resolvers, e.g. 'newest,nearest'.
I had to upgrade all ArtifactResolver calls to the new overloaded
version that takes a list of conflict resolvers, since if they're not
supplied then the component is forced to use the default conflict
resolver implementation (nearest). Any plugins that use manual
resolution would have to change accordingly to take advantage of
POM-configured conflict resolution.
This was probably the best way to go. The only plugins that should be
doing this would be those that have to locate artifacts outside the
project anyway (or don't operate on a project in the first place,
like archetype), so it shouldn't be inconsistent.
The other sticking point was how to propagate
ConflictResolverNotFoundException. I'd rather not wrap it up in a
misleading checked exception, and I'm not sure how people feel about
adding it as a further checked exception in the appropriate places.
Since you're only adding that to the additive methods, I don't see
any problem with also adding a checked exception. I certainly
wouldn't add it to existing methods.
I'll write an IT tomorrow than demonstrates this behaviour, but it's
pretty easy to try out.
Neat!
We're going to have to do some work on the repository metadata where
there are missing versions etc that will make ranges less effective,
but building a sample suite of expected projects and behaviours would
be really helpful for moving forward.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
