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/04/23 19:01:00 UTC
[m2] Conflict resolvers
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:
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 25/04/07, Brett Porter <br...@apache.org> wrote:
> Cool, I'll take a look - since there seems to be a lot of talk about
> maven-artifact right now, maybe this could be added to a list of
> things to discuss while folks are f2f for the upcoming conferences.
> I'll send a separate mail.
Thanks Brett. I've attached a subsequent patch which remedies (1) and
(2). Let me know how you'd like to take this forward, until then I'll
move onto something else.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Brett Porter <br...@apache.org>.
Cool, I'll take a look - since there seems to be a lot of talk about
maven-artifact right now, maybe this could be added to a list of
things to discuss while folks are f2f for the upcoming conferences.
I'll send a separate mail.
On 23/04/2007, at 7:01 PM, 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:
>
> 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: 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: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 18/05/07, Jason van Zyl <ja...@maven.org> wrote:
> I'll be home on Monday and then I'll upload the spec I've written for
> version resolution. Your code can be used but let's have folks look
> at the spec first.
Cool, I'll look forward to having a read.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Brett Porter <br...@apache.org>.
Heh. Perils of writing a mail on a plane to be sent when you
arrive... you answered me before I even sent it :)
On 18/05/2007, at 4:16 PM, Jason van Zyl wrote:
> I'll be home on Monday and then I'll upload the spec I've written
> for version resolution. Your code can be used but let's have folks
> look at the spec first.
>
> On 17 May 07, at 10:06 AM 17 May 07, Mark Hobson wrote:
>
>> On 30/04/07, Brett Porter <br...@apache.org> wrote:
>>> As Mark further explained, I think his proposal is entirely
>>> different
>>> and could be adapted to whatever strategy you apply in general here.
>>
>> Was there any consensus on whether to apply MNG-612 to 2.0.x after
>> all
>> the conferences?
>>
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
I'll be home on Monday and then I'll upload the spec I've written for
version resolution. Your code can be used but let's have folks look
at the spec first.
On 17 May 07, at 10:06 AM 17 May 07, Mark Hobson wrote:
> On 30/04/07, Brett Porter <br...@apache.org> wrote:
>> As Mark further explained, I think his proposal is entirely different
>> and could be adapted to whatever strategy you apply in general here.
>
> Was there any consensus on whether to apply MNG-612 to 2.0.x after all
> the conferences?
>
> 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
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 22/06/07, Brett Porter <br...@apache.org> wrote:
> Maybe I misunderstood, but I don't think the intention of this patch
> is to allow other people to plug in their own, but simply allowing
> them to use alternatives we've provided. The pluggable part certainly
> needs to come later.
Yep, and in 2.0.x it's only configurable by adding an extension to the
Maven installation. I'm sure users that undertake this will be happy
to accept the caveats that this involves.
> If that's the case, I don't understand why conflict resolution is
> incompatible with being graph based. You still need to make decisions
> at the graph nodes, and the same strategies probably apply.
Yep, they will still be required, although it's quite likely that they
will implemented using a different API.
[snip]
> I'd actually like to see this committed to trunk. It would give
> people the option to see it in action, and it would mean the future
> solution must be at least as functional. I'm not really big on adding
> features to 2.0.x either, as I've said before.
I certainly agree with committing to trunk, and then it can be
superseded as and when the new code is ready. I really can't see any
harm in committing to 2.0.x though, removing hardcoded assumptions can
only be good.
> Mark, would this suit you?
I really need it in 2.0.x since I can't justify moving the development
team onto a pre-alpha 2.1. We took a big leap of faith from 1.x to
2.0 when the first alpha came out and lost a lot of time due to
teething issues. We're now enjoying the stability of 2.0.x and loath
to repeat the process.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 28/06/07, Brett Porter <br...@apache.org> wrote:
> On 29/06/2007, at 2:35 AM, Mark Hobson wrote:
> > 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.
Unfortunately these are existing methods in maven-core, hence I didn't
want to add any checked exceptions. See the TODOs in the diff for
propagating ConflictResolverNotFoundException.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 28/06/07, Brett Porter <br...@apache.org> wrote:
> On 29/06/2007, at 2:35 AM, Mark Hobson wrote:
> > I'll write an IT tomorrow than demonstrates this behaviour, but it's
> > pretty easy to try out.
>
> Neat!
Added it0125 to verify switching to newest-wins conflict resolution.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Brett Porter <br...@apache.org>.
On 29/06/2007, at 2:35 AM, Mark Hobson wrote:
> On 28/06/07, Brett Porter <br...@apache.org> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
On 2 Jul 07, at 7:37 AM 2 Jul 07, Mark Hobson wrote:
> On 29/06/07, Jason van Zyl <ja...@maven.org> wrote:
>> Put it in the wiki.
>
> Consider it put:
>
> http://docs.codehaus.org/display/MAVEN/Conflict+Resolvers
>
Very nice, thanks.
> Feedback welcome.
>
Will take a look today.
> 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
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 29/06/07, Jason van Zyl <ja...@maven.org> wrote:
> Put it in the wiki.
Consider it put:
http://docs.codehaus.org/display/MAVEN/Conflict+Resolvers
Feedback welcome.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
Put it in the wiki.
On 29 Jun 07, at 3:28 AM 29 Jun 07, Mark Hobson wrote:
> On 28/06/07, Jason van Zyl <ja...@maven.org> wrote:
>> As long as you track this in your proposal and end result amounts to
>> what this is going to look like in a v4 POM in 2.1 where hopefully
>> we'll have something nicer like:
>>
>> <conflictResolvers>
>> <conflictResolver>x</conflictResolver>
>> <conflictResolver>y</conflictResolver>
>> <conflictResolver>z</conflictResolver>
>> </conflictResolver>
>>
>> And then in 2.1 if these strategies are employed we can look for the
>> property and map it into the POM before the build plan is executed.
>>
>> Even though a graph will be used I don't think the identifiers
>> describing the strategy would need to change. So if this winds up
>> getting exposed in the POM lets pick some meaningful understandable
>> names before you put this in finally as if this goes in the POMs the
>> ids for the strategies at the very least should remain the same.
>
> That's along the lines that I was thinking. So to summarise, in 2.0.x
> we'd use the following syntax:
>
> <properties>
> <mavenConflictResolvers>x,y,z</mavenConflictResolvers>
> </properties>
>
> Whereas in 2.1.x the property syntax will be supported but deprecated
> and we'll use the following preferred syntax:
>
> <conflictResolvers>
> <conflictResolver>x</conflictResolver>
> <conflictResolver>y</conflictResolver>
> <conflictResolver>z</conflictResolver>
> </conflictResolver>
>
> Possibly as a child element of <dependencies>.
>
> The currently implemented conflict resolvers are named as follows
> (descriptions copied from the Javadoc):
>
> - nearest: Resolves conflicting artifacts by always selecting the
> nearest declaration. Nearest is defined as the declaration that has
> the least transitive steps away from the project being built.
>
> - farthest: Resolves conflicting artifacts by always selecting the
> farthest declaration. Farthest is defined as the declaration that has
> the most transitive steps away from the project being built.
>
> - newest: Resolves conflicting artifacts by always selecting the
> newest declaration. Newest is defined as the declaration whose version
> is greater according to ArtifactVersion.compareTo.
>
> - oldest: Resolves conflicting artifacts by always selecting the
> oldest declaration. Oldest is defined as the declaration whose version
> is less according to ArtifactVersion.compareTo.
>
> The default is nearest for backwards-compatibility.
>
> If everyone is happy with the MNG-612 branch then I'd like to see it
> land on 2.0.x and 2.1.x. See it0125 for an example of it in action.
> Once the dust has settled on this discussion I'll wiki it up as
> agreed. (Or should the proposal come first? ;)
>
> I've got next week to continue on this and the other dependency tasks
> I've been working on, so it'd be good to wrap this all up by then
> before I have to move onto other work.
>
> 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
Re: [m2] Conflict resolvers
Posted by Brett Porter <br...@apache.org>.
I think the extension points need to be configured by the pom, so
that projects build consistently on any installation. I continue to
think the 'build the project' POM is different to the 'represent the
project' POM that winds up in the repository and other places and
should be separated at some point.
I like the idea of adding configuration for extensions. I don't think
there should need to be any general built in configuration point as
that can generally be done by other aspects of the POM.
Sounds like a good one for the wiki :)
- Brett
On 30/06/2007, at 4:15 AM, Kenney Westerhof wrote:
> Hi,
>
> Just some thoughts here.
>
> Maven can be customized with plugins. That is, the build currently is,
> but what is the build? It seems dependency resolution is not part
> of it.
>
> What about we extend the <extensions> a bit, like this:
>
> <extensions>
> <extension>
> <groupId/>
> <artifactId/>
> <version/>
> <!-- so far no changes, but this is new: -->
> <configuration>
> </configuration>
> </extension>
> </extensions>
>
> this way you can customize whatever components are present in the
> extension.
> for instance, a 'ConflictResolver' component.
> This doesn't allow for built-in components to be customized
> though.. and i'm not sure
> we want that kind of info like this in the pom anyway - the system
> behind it
> should be totally hidden.
>
> Perhaps something like configurable extension points would be
> better. But we cannot
> foresee all possible things to customize, like conflictresolvers
> etc.. Within a short
> amount of time the pom will become very complex and polluted...
>
> Maybe allowing custom namespaces to extend the pom.. not too
> portable either..
>
> I'm just afraid we'll pollute the pom too much with all kinds of tags
> for this and that; something more generic may be more future proof
> and have
> less changes to the pom.
>
> -- Kenney
>
>
> Mark Hobson wrote:
>> On 28/06/07, Jason van Zyl <ja...@maven.org> wrote:
>>> As long as you track this in your proposal and end result amounts to
>>> what this is going to look like in a v4 POM in 2.1 where hopefully
>>> we'll have something nicer like:
>>>
>>> <conflictResolvers>
>>> <conflictResolver>x</conflictResolver>
>>> <conflictResolver>y</conflictResolver>
>>> <conflictResolver>z</conflictResolver>
>>> </conflictResolver>
>>>
>>> And then in 2.1 if these strategies are employed we can look for the
>>> property and map it into the POM before the build plan is executed.
>>>
>>> Even though a graph will be used I don't think the identifiers
>>> describing the strategy would need to change. So if this winds up
>>> getting exposed in the POM lets pick some meaningful understandable
>>> names before you put this in finally as if this goes in the POMs the
>>> ids for the strategies at the very least should remain the same.
>> That's along the lines that I was thinking. So to summarise, in
>> 2.0.x
>> we'd use the following syntax:
>> <properties>
>> <mavenConflictResolvers>x,y,z</mavenConflictResolvers>
>> </properties>
>> Whereas in 2.1.x the property syntax will be supported but deprecated
>> and we'll use the following preferred syntax:
>> <conflictResolvers>
>> <conflictResolver>x</conflictResolver>
>> <conflictResolver>y</conflictResolver>
>> <conflictResolver>z</conflictResolver>
>> </conflictResolver>
>> Possibly as a child element of <dependencies>.
>> The currently implemented conflict resolvers are named as follows
>> (descriptions copied from the Javadoc):
>> - nearest: Resolves conflicting artifacts by always selecting the
>> nearest declaration. Nearest is defined as the declaration that has
>> the least transitive steps away from the project being built.
>> - farthest: Resolves conflicting artifacts by always selecting the
>> farthest declaration. Farthest is defined as the declaration that has
>> the most transitive steps away from the project being built.
>> - newest: Resolves conflicting artifacts by always selecting the
>> newest declaration. Newest is defined as the declaration whose
>> version
>> is greater according to ArtifactVersion.compareTo.
>> - oldest: Resolves conflicting artifacts by always selecting the
>> oldest declaration. Oldest is defined as the declaration whose
>> version
>> is less according to ArtifactVersion.compareTo.
>> The default is nearest for backwards-compatibility.
>> If everyone is happy with the MNG-612 branch then I'd like to see it
>> land on 2.0.x and 2.1.x. See it0125 for an example of it in action.
>> Once the dust has settled on this discussion I'll wiki it up as
>> agreed. (Or should the proposal come first? ;)
>> I've got next week to continue on this and the other dependency tasks
>> I've been working on, so it'd be good to wrap this all up by then
>> before I have to move onto other work.
>> Cheers,
>> Mark
>> ---------------------------------------------------------------------
>> 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: [m2] Conflict resolvers
Posted by Kenney Westerhof <ke...@apache.org>.
Hi,
Just some thoughts here.
Maven can be customized with plugins. That is, the build currently is,
but what is the build? It seems dependency resolution is not part of it.
What about we extend the <extensions> a bit, like this:
<extensions>
<extension>
<groupId/>
<artifactId/>
<version/>
<!-- so far no changes, but this is new: -->
<configuration>
</configuration>
</extension>
</extensions>
this way you can customize whatever components are present in the extension.
for instance, a 'ConflictResolver' component.
This doesn't allow for built-in components to be customized though.. and i'm not sure
we want that kind of info like this in the pom anyway - the system behind it
should be totally hidden.
Perhaps something like configurable extension points would be better. But we cannot
foresee all possible things to customize, like conflictresolvers etc.. Within a short
amount of time the pom will become very complex and polluted...
Maybe allowing custom namespaces to extend the pom.. not too portable either..
I'm just afraid we'll pollute the pom too much with all kinds of tags
for this and that; something more generic may be more future proof and have
less changes to the pom.
-- Kenney
Mark Hobson wrote:
> On 28/06/07, Jason van Zyl <ja...@maven.org> wrote:
>> As long as you track this in your proposal and end result amounts to
>> what this is going to look like in a v4 POM in 2.1 where hopefully
>> we'll have something nicer like:
>>
>> <conflictResolvers>
>> <conflictResolver>x</conflictResolver>
>> <conflictResolver>y</conflictResolver>
>> <conflictResolver>z</conflictResolver>
>> </conflictResolver>
>>
>> And then in 2.1 if these strategies are employed we can look for the
>> property and map it into the POM before the build plan is executed.
>>
>> Even though a graph will be used I don't think the identifiers
>> describing the strategy would need to change. So if this winds up
>> getting exposed in the POM lets pick some meaningful understandable
>> names before you put this in finally as if this goes in the POMs the
>> ids for the strategies at the very least should remain the same.
>
> That's along the lines that I was thinking. So to summarise, in 2.0.x
> we'd use the following syntax:
>
> <properties>
> <mavenConflictResolvers>x,y,z</mavenConflictResolvers>
> </properties>
>
> Whereas in 2.1.x the property syntax will be supported but deprecated
> and we'll use the following preferred syntax:
>
> <conflictResolvers>
> <conflictResolver>x</conflictResolver>
> <conflictResolver>y</conflictResolver>
> <conflictResolver>z</conflictResolver>
> </conflictResolver>
>
> Possibly as a child element of <dependencies>.
>
> The currently implemented conflict resolvers are named as follows
> (descriptions copied from the Javadoc):
>
> - nearest: Resolves conflicting artifacts by always selecting the
> nearest declaration. Nearest is defined as the declaration that has
> the least transitive steps away from the project being built.
>
> - farthest: Resolves conflicting artifacts by always selecting the
> farthest declaration. Farthest is defined as the declaration that has
> the most transitive steps away from the project being built.
>
> - newest: Resolves conflicting artifacts by always selecting the
> newest declaration. Newest is defined as the declaration whose version
> is greater according to ArtifactVersion.compareTo.
>
> - oldest: Resolves conflicting artifacts by always selecting the
> oldest declaration. Oldest is defined as the declaration whose version
> is less according to ArtifactVersion.compareTo.
>
> The default is nearest for backwards-compatibility.
>
> If everyone is happy with the MNG-612 branch then I'd like to see it
> land on 2.0.x and 2.1.x. See it0125 for an example of it in action.
> Once the dust has settled on this discussion I'll wiki it up as
> agreed. (Or should the proposal come first? ;)
>
> I've got next week to continue on this and the other dependency tasks
> I've been working on, so it'd be good to wrap this all up by then
> before I have to move onto other work.
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> 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: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 28/06/07, Jason van Zyl <ja...@maven.org> wrote:
> As long as you track this in your proposal and end result amounts to
> what this is going to look like in a v4 POM in 2.1 where hopefully
> we'll have something nicer like:
>
> <conflictResolvers>
> <conflictResolver>x</conflictResolver>
> <conflictResolver>y</conflictResolver>
> <conflictResolver>z</conflictResolver>
> </conflictResolver>
>
> And then in 2.1 if these strategies are employed we can look for the
> property and map it into the POM before the build plan is executed.
>
> Even though a graph will be used I don't think the identifiers
> describing the strategy would need to change. So if this winds up
> getting exposed in the POM lets pick some meaningful understandable
> names before you put this in finally as if this goes in the POMs the
> ids for the strategies at the very least should remain the same.
That's along the lines that I was thinking. So to summarise, in 2.0.x
we'd use the following syntax:
<properties>
<mavenConflictResolvers>x,y,z</mavenConflictResolvers>
</properties>
Whereas in 2.1.x the property syntax will be supported but deprecated
and we'll use the following preferred syntax:
<conflictResolvers>
<conflictResolver>x</conflictResolver>
<conflictResolver>y</conflictResolver>
<conflictResolver>z</conflictResolver>
</conflictResolver>
Possibly as a child element of <dependencies>.
The currently implemented conflict resolvers are named as follows
(descriptions copied from the Javadoc):
- nearest: Resolves conflicting artifacts by always selecting the
nearest declaration. Nearest is defined as the declaration that has
the least transitive steps away from the project being built.
- farthest: Resolves conflicting artifacts by always selecting the
farthest declaration. Farthest is defined as the declaration that has
the most transitive steps away from the project being built.
- newest: Resolves conflicting artifacts by always selecting the
newest declaration. Newest is defined as the declaration whose version
is greater according to ArtifactVersion.compareTo.
- oldest: Resolves conflicting artifacts by always selecting the
oldest declaration. Oldest is defined as the declaration whose version
is less according to ArtifactVersion.compareTo.
The default is nearest for backwards-compatibility.
If everyone is happy with the MNG-612 branch then I'd like to see it
land on 2.0.x and 2.1.x. See it0125 for an example of it in action.
Once the dust has settled on this discussion I'll wiki it up as
agreed. (Or should the proposal come first? ;)
I've got next week to continue on this and the other dependency tasks
I've been working on, so it'd be good to wrap this all up by then
before I have to move onto other work.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Brett Porter <br...@apache.org>.
My understanding was that it was all experimental at this point to
see what actually worked, then need to decide where it lands.
Requiring a change in the install is no good - it ruins the install
for general use and is more hassle than it's worth. I think the
(undocumented, unsupported) property is fine - it's just as "use at
your own risk" as dropping something into the install dir.
I've no problems with this landing on trunk and building up test
cases for the relevant uses of it to be upheld under any later
changes to the artifact mechanism.
I'm still not convinced of it landing in a 2.0.x release because it's
a new feature that won't persist in its current form (at least in the
way it's exposed). That said, I can't see how the feature would
really change in 2.1 other than, obviously, in the implementation.
You're still going to be selecting newest or nearest or whatever
against a set of graph of dependencies, and the results should be
essentially the same.
Perhaps we can maintain a branch that is 2.0.x + this patch. It's
otherwise just as stable as 2.0.x, you just have to build it from
source yourself and read the warning label on the tin.
- Brett
On 29/06/2007, at 4:48 AM, Mark Hobson wrote:
> On 28/06/07, Jason van Zyl <ja...@maven.org> wrote:
>> I thought we agreed that this was not to surface in a POM? If you put
>> that in there now people will start using it. I thought you were
>> going to be able to do this strictly by changes to your installation?
>
> The initial way I got this working was by modifying the installation
> to override components.xml. I then looked again at MNG-2771 and tried
> to achieve the same via a POM extension, but after chatting to Kenney
> we concluded that this doesn't work in 2.0.x nor 2.1 yet, so I added
> it0124 to show this. Brett then suggested using a POM property to
> make the conflict resolver configuration project-specific, which is
> what I've just done.
>
> If this exposes too much then I'm happy to cut it back down to an
> installation modification for now.
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> 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: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
On 28 Jun 07, at 11:48 AM 28 Jun 07, Mark Hobson wrote:
> On 28/06/07, Jason van Zyl <ja...@maven.org> wrote:
>> I thought we agreed that this was not to surface in a POM? If you put
>> that in there now people will start using it. I thought you were
>> going to be able to do this strictly by changes to your installation?
>
> The initial way I got this working was by modifying the installation
> to override components.xml. I then looked again at MNG-2771 and tried
> to achieve the same via a POM extension, but after chatting to Kenney
> we concluded that this doesn't work in 2.0.x nor 2.1 yet, so I added
> it0124 to show this. Brett then suggested using a POM property to
> make the conflict resolver configuration project-specific, which is
> what I've just done.
>
> If this exposes too much then I'm happy to cut it back down to an
> installation modification for now.
>
As long as you track this in your proposal and end result amounts to
what this is going to look like in a v4 POM in 2.1 where hopefully
we'll have something nicer like:
<conflictResolvers>
<conflictResolver>x</conflictResolver>
<conflictResolver>y</conflictResolver>
<conflictResolver>z</conflictResolver>
</conflictResolver>
And then in 2.1 if these strategies are employed we can look for the
property and map it into the POM before the build plan is executed.
Even though a graph will be used I don't think the identifiers
describing the strategy would need to change. So if this winds up
getting exposed in the POM lets pick some meaningful understandable
names before you put this in finally as if this goes in the POMs the
ids for the strategies at the very least should remain the same.
> 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
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 28/06/07, Jason van Zyl <ja...@maven.org> wrote:
> I thought we agreed that this was not to surface in a POM? If you put
> that in there now people will start using it. I thought you were
> going to be able to do this strictly by changes to your installation?
The initial way I got this working was by modifying the installation
to override components.xml. I then looked again at MNG-2771 and tried
to achieve the same via a POM extension, but after chatting to Kenney
we concluded that this doesn't work in 2.0.x nor 2.1 yet, so I added
it0124 to show this. Brett then suggested using a POM property to
make the conflict resolver configuration project-specific, which is
what I've just done.
If this exposes too much then I'm happy to cut it back down to an
installation modification for now.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
On 28 Jun 07, at 9:35 AM 28 Jun 07, Mark Hobson wrote:
> On 28/06/07, Brett Porter <br...@apache.org> 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.
>
> 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 thought we agreed that this was not to surface in a POM? If you put
that in there now people will start using it. I thought you were
going to be able to do this strictly by changes to your installation?
> 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.
>
> 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.
>
> I'll write an IT tomorrow than demonstrates this behaviour, but it's
> pretty easy to try out.
>
> 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
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 28/06/07, Brett Porter <br...@apache.org> 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.
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.
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.
I'll write an IT tomorrow than demonstrates this behaviour, but it's
pretty easy to try out.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 25/06/07, Kenney Westerhof <ke...@apache.org> wrote:
> Mark Hobson wrote:
> > Now, there are three solutions: 1) Update all other components that
> > also depend on this dependency so there are no version conflicts; 2)
> > Add the bug fix version to the main project's depMan; 3) Rely on the
> > conflict resolution strategy to resolve the required version.
> >
> > (1) becomes extremely impractical in large projects; (2) works, but
> > over time, as more and more versions are fixed in depMan, it starts to
> > resemble Maven 1's flattened list of dependencies, thus causing even
> > more maintenance problems; (3) seems like the most natural place to
> > make these decisions.
>
> 2 doesn't work without stripping all version tags on that dependency from
> all modules, as depMan only provides defaults for direct deps.
Not sure if I understand you here - my understanding is:
- depMan overrides versions for transitive dependencies
- direct dependencies override versions from depMan
> 3 doesn't always work - if you build a sub-tree of modules that doesn't
> have any dep with the bugfix version you still get the older one, so, what
> version you'll get will depend on where you build (how big the reactor is).
True, but I think this is preferable to a project's dependencies'
versions changing depending on their depth.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Brett Porter <br...@apache.org>.
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.
- Brett
On 28/06/2007, at 2:35 AM, Mark Hobson wrote:
> On 27/06/07, Mark Hobson <ma...@gmail.com> wrote:
>> The alternative of using role hints would be preferable, so thanks
>> for
>> the pointers, I'll try implementing this now. What's the best place
>> in the POM to configure the role hint with changing the schema
>> though?
>> Is there a reserved namespace of properties we could use, e.g.
>> maven.* so I could use maven.conflict.resolver=newest perhaps?
>
> I'm not too clear on how you see a POM property getting through to the
> DefaultArtifactCollector to obtain the default list of
> ConflictResolvers. Currently, the existing ArtifactCollector collect
> method now delegates to an overloaded version that takes a list of
> conflict resolvers:
>
> ArtifactResolutionResult collect(..., List conflictResolvers )
>
> So when delegating it needs to build a list of conflict resolvers to
> use by default. Previously this was done with a ConflictResolver
> field that Plexus injected the default role-hint implementation into,
> which could then be overridden from a POM extension components.xml.
>
> Now, if we take the route of specifying the role-hint in the POM
> somehow, how would this be cleanly propagated to DAC?
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> 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: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 27/06/07, Mark Hobson <ma...@gmail.com> wrote:
> The alternative of using role hints would be preferable, so thanks for
> the pointers, I'll try implementing this now. What's the best place
> in the POM to configure the role hint with changing the schema though?
> Is there a reserved namespace of properties we could use, e.g.
> maven.* so I could use maven.conflict.resolver=newest perhaps?
I'm not too clear on how you see a POM property getting through to the
DefaultArtifactCollector to obtain the default list of
ConflictResolvers. Currently, the existing ArtifactCollector collect
method now delegates to an overloaded version that takes a list of
conflict resolvers:
ArtifactResolutionResult collect(..., List conflictResolvers )
So when delegating it needs to build a list of conflict resolvers to
use by default. Previously this was done with a ConflictResolver
field that Plexus injected the default role-hint implementation into,
which could then be overridden from a POM extension components.xml.
Now, if we take the route of specifying the role-hint in the POM
somehow, how would this be cleanly propagated to DAC?
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
Hi Brett,
Thanks for the reply. I was trying to get MNG-2771 POM extensions
working yesterday and had troubles with both 2.0.x and 2.1. I spoke
to Kenney on IRC about it and he seemed to think a fix would be easy
enough, so I added IT0124 to demonstrate the problem. Kenney, did you
manage to have a look into this?
The alternative of using role hints would be preferable, so thanks for
the pointers, I'll try implementing this now. What's the best place
in the POM to configure the role hint with changing the schema though?
Is there a reserved namespace of properties we could use, e.g.
maven.* so I could use maven.conflict.resolver=newest perhaps?
Cheers,
Mark
On 27/06/07, Brett Porter <br...@apache.org> wrote:
> Hi Mark,
>
> I didn't follow whether you got a response on MNG-2771, but your
> approach is right (ie, follow wagon).
>
> Basically:
> 1) use contextualizable to grab the plexus container
> 2) lookup conflict resolvers by role hint (a pom/settings property
> might be a good way to trigger this)
> 3) use the conflict resolver you want
>
> You may want to create a conflict resolver factory to do these bits,
> and then call on it to get the desired resolver by role hint just to
> avoid adding the contextualizable bit to the existing classes - not
> sure if that's an issue or not.
>
> Cheers,
> Brett
>
> On 26/06/2007, at 2:06 AM, Mark Hobson wrote:
>
> > On 24/06/07, Brett Porter <br...@apache.org> wrote:
> >> Sorry :(
> >>
> >> At the time, the repository data (mostly converted from m1) wasn't
> >> suited to it and you got things you didn't expect. I always expected
> >> you'd be able to turn it on and manage the dependencies properly but
> >> the implementation of that didn't happen.
> >
> > Yeah, thought it may be a hangover from the early days.. :(
> >
> >> Can you pull this off through the <extensions> tag in the POM as
> >> Kenney suggested? It seems reasonable, and if so, then I feel a
> >> little more comfortable with it.
> >
> > This would be ideal, but I couldn't get it working in 2.0.x. I
> > assumed this only worked in 2.1, but I've just tried and couldn't get
> > it working in that either. If Kenney, or someone familiar with
> > MNG-2771, could validate my approach:
> >
> > 1) maven-artifact/META-INF/plexus/components.xml defines:
> > a) ConflictResolver implementations with various role-hints,
> > including default
> > b) ArtifactCollector implementation with default ConflictResolver
> > as a requirement
> > 2) my project declares an extension jar that just contains a
> > META-INF/plexus/components.xml that redefines the ConflictResolver
> > implementation for default role-hint
> >
> > In both 2.0.x and 2.1 the extension components.xml doesn't appear to
> > override the Maven components.xml.
> >
> > An alternative, and preferred, method of configuration would be to use
> > role-hints to switch conflict resolvers, similar to Wagon. I'm not
> > overly familiar with Plexus enough to know the best way to implement
> > this - if DefaultArtifactCollector requires a ConflictResolver, how
> > could a role-hint be positioned to switch the implementation used
> > during composition? Also, how could this role-hint be configured in
> > the POM without changing the schema?
> >
> >> I don't really want to expose any functionality that requires a
> >> customised Maven to run a project, though - that seems like we're
> >> putting something in that will only be used by you :) It'll likely
> >> break building other projects using that installation, or not being
> >> able to build the projects on a different installation (Without hints
> >> to help). If you're happy using a customised Maven, maybe you're best
> >> building your own branch off the latest 2.0.x that includes the
> >> patch?
> >
> > Sure, but I'd like to see if we could get extensions working first.
> >
> >> I'm still all for rolling it onto trunk and putting in example
> >> projects that let us see this in action and help drive the use cases
> >> for it going forward.
> >
> > Cheers,
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > 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: [m2] Conflict resolvers
Posted by Brett Porter <br...@apache.org>.
Hi Mark,
I didn't follow whether you got a response on MNG-2771, but your
approach is right (ie, follow wagon).
Basically:
1) use contextualizable to grab the plexus container
2) lookup conflict resolvers by role hint (a pom/settings property
might be a good way to trigger this)
3) use the conflict resolver you want
You may want to create a conflict resolver factory to do these bits,
and then call on it to get the desired resolver by role hint just to
avoid adding the contextualizable bit to the existing classes - not
sure if that's an issue or not.
Cheers,
Brett
On 26/06/2007, at 2:06 AM, Mark Hobson wrote:
> On 24/06/07, Brett Porter <br...@apache.org> wrote:
>> Sorry :(
>>
>> At the time, the repository data (mostly converted from m1) wasn't
>> suited to it and you got things you didn't expect. I always expected
>> you'd be able to turn it on and manage the dependencies properly but
>> the implementation of that didn't happen.
>
> Yeah, thought it may be a hangover from the early days.. :(
>
>> Can you pull this off through the <extensions> tag in the POM as
>> Kenney suggested? It seems reasonable, and if so, then I feel a
>> little more comfortable with it.
>
> This would be ideal, but I couldn't get it working in 2.0.x. I
> assumed this only worked in 2.1, but I've just tried and couldn't get
> it working in that either. If Kenney, or someone familiar with
> MNG-2771, could validate my approach:
>
> 1) maven-artifact/META-INF/plexus/components.xml defines:
> a) ConflictResolver implementations with various role-hints,
> including default
> b) ArtifactCollector implementation with default ConflictResolver
> as a requirement
> 2) my project declares an extension jar that just contains a
> META-INF/plexus/components.xml that redefines the ConflictResolver
> implementation for default role-hint
>
> In both 2.0.x and 2.1 the extension components.xml doesn't appear to
> override the Maven components.xml.
>
> An alternative, and preferred, method of configuration would be to use
> role-hints to switch conflict resolvers, similar to Wagon. I'm not
> overly familiar with Plexus enough to know the best way to implement
> this - if DefaultArtifactCollector requires a ConflictResolver, how
> could a role-hint be positioned to switch the implementation used
> during composition? Also, how could this role-hint be configured in
> the POM without changing the schema?
>
>> I don't really want to expose any functionality that requires a
>> customised Maven to run a project, though - that seems like we're
>> putting something in that will only be used by you :) It'll likely
>> break building other projects using that installation, or not being
>> able to build the projects on a different installation (Without hints
>> to help). If you're happy using a customised Maven, maybe you're best
>> building your own branch off the latest 2.0.x that includes the
>> patch?
>
> Sure, but I'd like to see if we could get extensions working first.
>
>> I'm still all for rolling it onto trunk and putting in example
>> projects that let us see this in action and help drive the use cases
>> for it going forward.
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> 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: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 24/06/07, Brett Porter <br...@apache.org> wrote:
> Sorry :(
>
> At the time, the repository data (mostly converted from m1) wasn't
> suited to it and you got things you didn't expect. I always expected
> you'd be able to turn it on and manage the dependencies properly but
> the implementation of that didn't happen.
Yeah, thought it may be a hangover from the early days.. :(
> Can you pull this off through the <extensions> tag in the POM as
> Kenney suggested? It seems reasonable, and if so, then I feel a
> little more comfortable with it.
This would be ideal, but I couldn't get it working in 2.0.x. I
assumed this only worked in 2.1, but I've just tried and couldn't get
it working in that either. If Kenney, or someone familiar with
MNG-2771, could validate my approach:
1) maven-artifact/META-INF/plexus/components.xml defines:
a) ConflictResolver implementations with various role-hints,
including default
b) ArtifactCollector implementation with default ConflictResolver
as a requirement
2) my project declares an extension jar that just contains a
META-INF/plexus/components.xml that redefines the ConflictResolver
implementation for default role-hint
In both 2.0.x and 2.1 the extension components.xml doesn't appear to
override the Maven components.xml.
An alternative, and preferred, method of configuration would be to use
role-hints to switch conflict resolvers, similar to Wagon. I'm not
overly familiar with Plexus enough to know the best way to implement
this - if DefaultArtifactCollector requires a ConflictResolver, how
could a role-hint be positioned to switch the implementation used
during composition? Also, how could this role-hint be configured in
the POM without changing the schema?
> I don't really want to expose any functionality that requires a
> customised Maven to run a project, though - that seems like we're
> putting something in that will only be used by you :) It'll likely
> break building other projects using that installation, or not being
> able to build the projects on a different installation (Without hints
> to help). If you're happy using a customised Maven, maybe you're best
> building your own branch off the latest 2.0.x that includes the patch?
Sure, but I'd like to see if we could get extensions working first.
> I'm still all for rolling it onto trunk and putting in example
> projects that let us see this in action and help drive the use cases
> for it going forward.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Kenney Westerhof <ke...@apache.org>.
Mark Hobson wrote:
> On 22/06/07, Jason van Zyl <ja...@maven.org> wrote:
>> On 22 Jun 07, at 3:15 AM 22 Jun 07, Mark Hobson wrote:
>> > As mentioned above, this requires a change in the Maven installation
>> > rather than the POM. Obviously far from ideal, but I'm happy to live
>> > with this for the huge gain in productivity.
>>
>> So how exactly does this help with your situation as I'm looking for
>> details as I'm loathe to put this in 2.0.x.
>
> Okay, imagine a project with a deep dependency tree where many
> dependencies bring in common dependencies at various levels.
> Initially, let's say there are no version conflicts amongst the
> dependencies. Now, a bug fix version of a common dependency is
> released and updated in the most appropriate place within the
> dependency tree. We now have a conflict and it is purely down to the
> depth of the updated dependency as to whether it is propagated through
> the whole project.
>
> Now, there are three solutions: 1) Update all other components that
> also depend on this dependency so there are no version conflicts; 2)
> Add the bug fix version to the main project's depMan; 3) Rely on the
> conflict resolution strategy to resolve the required version.
>
> (1) becomes extremely impractical in large projects; (2) works, but
> over time, as more and more versions are fixed in depMan, it starts to
> resemble Maven 1's flattened list of dependencies, thus causing even
> more maintenance problems; (3) seems like the most natural place to
> make these decisions.
2 doesn't work without stripping all version tags on that dependency from
all modules, as depMan only provides defaults for direct deps.
3 doesn't always work - if you build a sub-tree of modules that doesn't
have any dep with the bugfix version you still get the older one, so, what
version you'll get will depend on where you build (how big the reactor is).
-- Kenney
>
> This is basically our situation and why we need a more intuitive
> conflict resolver than nearest-wins. You can see that the concept of
> nearness becomes more and more arbitrary as the dependency tree grows.
>
>> From here, the plan is to supplement the highest-wins conflict
> resolution with version ranges to restrict mediation and release POMs
> for reproducibility, hence my work in this area too.
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> 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: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 22/06/07, Jason van Zyl <ja...@maven.org> wrote:
> On 22 Jun 07, at 3:15 AM 22 Jun 07, Mark Hobson wrote:
> > As mentioned above, this requires a change in the Maven installation
> > rather than the POM. Obviously far from ideal, but I'm happy to live
> > with this for the huge gain in productivity.
>
> So how exactly does this help with your situation as I'm looking for
> details as I'm loathe to put this in 2.0.x.
Okay, imagine a project with a deep dependency tree where many
dependencies bring in common dependencies at various levels.
Initially, let's say there are no version conflicts amongst the
dependencies. Now, a bug fix version of a common dependency is
released and updated in the most appropriate place within the
dependency tree. We now have a conflict and it is purely down to the
depth of the updated dependency as to whether it is propagated through
the whole project.
Now, there are three solutions: 1) Update all other components that
also depend on this dependency so there are no version conflicts; 2)
Add the bug fix version to the main project's depMan; 3) Rely on the
conflict resolution strategy to resolve the required version.
(1) becomes extremely impractical in large projects; (2) works, but
over time, as more and more versions are fixed in depMan, it starts to
resemble Maven 1's flattened list of dependencies, thus causing even
more maintenance problems; (3) seems like the most natural place to
make these decisions.
This is basically our situation and why we need a more intuitive
conflict resolver than nearest-wins. You can see that the concept of
nearness becomes more and more arbitrary as the dependency tree grows.
>From here, the plan is to supplement the highest-wins conflict
resolution with version ranges to restrict mediation and release POMs
for reproducibility, hence my work in this area too.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
On 26 Jun 07, at 8:49 AM 26 Jun 07, Mark Hobson wrote:
> On 26/06/07, Jason van Zyl <ja...@maven.org> wrote:
>> We can quickly try this little process if you put your proposal on
>> the main proposals page, then we'll put it in the pending section and
>> we can ask people to look at vote. Would probably be the easiest as
>> you have to field the feedback as a veto stops you dead in your
>> tracks.
>
> Looks like I need some privs for confluence - my username is mark.
>
There you go.
> 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
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 26/06/07, Jason van Zyl <ja...@maven.org> wrote:
> We can quickly try this little process if you put your proposal on
> the main proposals page, then we'll put it in the pending section and
> we can ask people to look at vote. Would probably be the easiest as
> you have to field the feedback as a veto stops you dead in your tracks.
Looks like I need some privs for confluence - my username is mark.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
On 26 Jun 07, at 2:40 AM 26 Jun 07, Mark Hobson wrote:
> On 25/06/07, Jason van Zyl <ja...@maven.org> wrote:
>> Mark,
>>
>> Can you help me make proposals like this more visible not only to
>> developers who might be interested, but to folks looking in at the
>> project for the first time.
>>
>> I am trying to collect all pertinent information to the project here:
>>
>> http://docs.codehaus.org/display/MAVEN/Home
>>
>> And I've reorganized the "Design" section to have a "Proposals" spot
>> so I think it would be cool while you are soliciting opinions to
>> summarize your plan there. Then people can read it while the proposal
>> is pending and then all these proposals will be in the wiki and stand
>> as a record of the evolution of the project. Do you think you could
>> summarize your emails and put it in that design section?
>
> Sure, I'll try to find a moment to summarise these changes on the
> wiki.
>
We can quickly try this little process if you put your proposal on
the main proposals page, then we'll put it in the pending section and
we can ask people to look at vote. Would probably be the easiest as
you have to field the feedback as a veto stops you dead in your tracks.
> 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
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 25/06/07, Jason van Zyl <ja...@maven.org> wrote:
> Mark,
>
> Can you help me make proposals like this more visible not only to
> developers who might be interested, but to folks looking in at the
> project for the first time.
>
> I am trying to collect all pertinent information to the project here:
>
> http://docs.codehaus.org/display/MAVEN/Home
>
> And I've reorganized the "Design" section to have a "Proposals" spot
> so I think it would be cool while you are soliciting opinions to
> summarize your plan there. Then people can read it while the proposal
> is pending and then all these proposals will be in the wiki and stand
> as a record of the evolution of the project. Do you think you could
> summarize your emails and put it in that design section?
Sure, I'll try to find a moment to summarise these changes on the wiki.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 25/06/07, Jason van Zyl <ja...@maven.org> wrote:
> Yah, sounds fine to be. It seems non-invasive and the onus is on you
> so if something goes wrong I know who to look for :-)
Okay, I'll work on trying to get it working via extensions a little
more then submit another patch for any final comments before
committing. Any probs and I'll join the witness protection programme
;)
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
On 25 Jun 07, at 9:29 AM 25 Jun 07, Mark Hobson wrote:
> On 24/06/07, Jason van Zyl <ja...@maven.org> wrote:
>> For the branch if it was 100% non-invasive i.e did not interfere at
>> all with _anything_ setup currently, did not change the default
>> conflict resolver and was undetectable by the common user, and you
>> took responsibility and ownership of any problems that arise then I
>> would be fine with it going into the branch.
>
> Yep, the patch merely pushes some hardcoded code into a pluggable
> component, so it works exactly as before with no changes required by
> the user. I'd be happy to handle any issues that would potentially
> arise from this refactor.
>
>> If you are using the
>> existing APIs and not changing them _at all_
>
> The only API changes are:
> - the currently empty interface ConflictResolver now has a usable
> resolveConflict method
This is used by no one externally so not a problem.
> - ArtifactCollector now has an further collect method that accepts a
> list of ConflictResolvers
>
This is additive so also not a problem.
> Technically, both of these changes could be avoided by not reusing the
> empty ConflictResolver interface, but whether this is really an issue
> is up for grabs.
>
I don't think it is because as far as I know you'll be the first on
the planet to use it.
>> and just plugging in
>> your mechanism which works by altering your installation then I don't
>> see how this will affect any current 2.0.x users.
>
> This would be the bare minimum, with the use of extensions as
> discussed elsewhere in this thread as the ideal.
>
>> You must also
>> express this new behavior with ITs and tests as the onus is on you to
>> make sure we can replicate the behavior but I don't think anyone can
>> promise anything vis-a-vis the code you use or the ultimate solution
>> in 2.1.
>
> Sure.
>
>> I can understand not wanting to use 2.1.x and that your solution gets
>> you where you need to be for 2.0.x. My only concern is that you don't
>> hose anything currently working. Any sort of conflict resolution
>> should be declarative and will be the case for 2.1.x. I don't think
>> it's overly useful in the trunk but put the code into both so they
>> stay in sync.
>
> I understand, the changes are non-intrusive and must be proactively
> enabled. I agree it'd be good to keep the branch and trunk in sync
> until the code is replaced for 2.1.
>
>> I'm fine with the additions as long as you take responsibility for
>> the changes. You'll have to wait a while as others may not be fine
>> with it so I'm sure you'll have a clear path this week sometime.
>
> Great, I'll look forward to any feedback.
>
Yah, sounds fine to be. It seems non-invasive and the onus is on you
so if something goes wrong I know who to look for :-)
> 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
Re: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
Mark,
Can you help me make proposals like this more visible not only to
developers who might be interested, but to folks looking in at the
project for the first time.
I am trying to collect all pertinent information to the project here:
http://docs.codehaus.org/display/MAVEN/Home
And I've reorganized the "Design" section to have a "Proposals" spot
so I think it would be cool while you are soliciting opinions to
summarize your plan there. Then people can read it while the proposal
is pending and then all these proposals will be in the wiki and stand
as a record of the evolution of the project. Do you think you could
summarize your emails and put it in that design section?
On 25 Jun 07, at 9:29 AM 25 Jun 07, Mark Hobson wrote:
> On 24/06/07, Jason van Zyl <ja...@maven.org> wrote:
>> For the branch if it was 100% non-invasive i.e did not interfere at
>> all with _anything_ setup currently, did not change the default
>> conflict resolver and was undetectable by the common user, and you
>> took responsibility and ownership of any problems that arise then I
>> would be fine with it going into the branch.
>
> Yep, the patch merely pushes some hardcoded code into a pluggable
> component, so it works exactly as before with no changes required by
> the user. I'd be happy to handle any issues that would potentially
> arise from this refactor.
>
>> If you are using the
>> existing APIs and not changing them _at all_
>
> The only API changes are:
> - the currently empty interface ConflictResolver now has a usable
> resolveConflict method
> - ArtifactCollector now has an further collect method that accepts a
> list of ConflictResolvers
>
> Technically, both of these changes could be avoided by not reusing the
> empty ConflictResolver interface, but whether this is really an issue
> is up for grabs.
>
>> and just plugging in
>> your mechanism which works by altering your installation then I don't
>> see how this will affect any current 2.0.x users.
>
> This would be the bare minimum, with the use of extensions as
> discussed elsewhere in this thread as the ideal.
>
>> You must also
>> express this new behavior with ITs and tests as the onus is on you to
>> make sure we can replicate the behavior but I don't think anyone can
>> promise anything vis-a-vis the code you use or the ultimate solution
>> in 2.1.
>
> Sure.
>
>> I can understand not wanting to use 2.1.x and that your solution gets
>> you where you need to be for 2.0.x. My only concern is that you don't
>> hose anything currently working. Any sort of conflict resolution
>> should be declarative and will be the case for 2.1.x. I don't think
>> it's overly useful in the trunk but put the code into both so they
>> stay in sync.
>
> I understand, the changes are non-intrusive and must be proactively
> enabled. I agree it'd be good to keep the branch and trunk in sync
> until the code is replaced for 2.1.
>
>> I'm fine with the additions as long as you take responsibility for
>> the changes. You'll have to wait a while as others may not be fine
>> with it so I'm sure you'll have a clear path this week sometime.
>
> Great, I'll look forward to any feedback.
>
> 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
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 24/06/07, Jason van Zyl <ja...@maven.org> wrote:
> For the branch if it was 100% non-invasive i.e did not interfere at
> all with _anything_ setup currently, did not change the default
> conflict resolver and was undetectable by the common user, and you
> took responsibility and ownership of any problems that arise then I
> would be fine with it going into the branch.
Yep, the patch merely pushes some hardcoded code into a pluggable
component, so it works exactly as before with no changes required by
the user. I'd be happy to handle any issues that would potentially
arise from this refactor.
> If you are using the
> existing APIs and not changing them _at all_
The only API changes are:
- the currently empty interface ConflictResolver now has a usable
resolveConflict method
- ArtifactCollector now has an further collect method that accepts a
list of ConflictResolvers
Technically, both of these changes could be avoided by not reusing the
empty ConflictResolver interface, but whether this is really an issue
is up for grabs.
> and just plugging in
> your mechanism which works by altering your installation then I don't
> see how this will affect any current 2.0.x users.
This would be the bare minimum, with the use of extensions as
discussed elsewhere in this thread as the ideal.
> You must also
> express this new behavior with ITs and tests as the onus is on you to
> make sure we can replicate the behavior but I don't think anyone can
> promise anything vis-a-vis the code you use or the ultimate solution
> in 2.1.
Sure.
> I can understand not wanting to use 2.1.x and that your solution gets
> you where you need to be for 2.0.x. My only concern is that you don't
> hose anything currently working. Any sort of conflict resolution
> should be declarative and will be the case for 2.1.x. I don't think
> it's overly useful in the trunk but put the code into both so they
> stay in sync.
I understand, the changes are non-intrusive and must be proactively
enabled. I agree it'd be good to keep the branch and trunk in sync
until the code is replaced for 2.1.
> I'm fine with the additions as long as you take responsibility for
> the changes. You'll have to wait a while as others may not be fine
> with it so I'm sure you'll have a clear path this week sometime.
Great, I'll look forward to any feedback.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
On 23 Jun 07, at 10:35 PM 23 Jun 07, Brett Porter wrote:
>
> On 22/06/2007, at 8:15 PM, Mark Hobson wrote:
>
>> On 22/06/07, Brett Porter <br...@apache.org> wrote:
>>> It's never been an alternative, but it was implemented as "newest
>>> wins" in an early alpha.
>>
>> Curse the person who switched to nearest! ;)
>
> Sorry :(
>
> At the time, the repository data (mostly converted from m1) wasn't
> suited to it and you got things you didn't expect. I always
> expected you'd be able to turn it on and manage the dependencies
> properly but the implementation of that didn't happen.
>
>>
>>> > How would anyone select a different strategy? This would require a
>>> > change to the POM to even turn on any alternatives. Even if the
>>> API
>>> > for the resolution was completely hidden something fundamental
>>> > would have to change i.e. the POM in order to activate it. No?
>>>
>>> Yes, I think it'd require a POM change to activate, so I'm more in
>>> favour of it being a starting point in 2.1.
>>
>> As mentioned above, this requires a change in the Maven installation
>> rather than the POM. Obviously far from ideal, but I'm happy to live
>> with this for the huge gain in productivity.
>
> Can you pull this off through the <extensions> tag in the POM as
> Kenney suggested? It seems reasonable, and if so, then I feel a
> little more comfortable with it.
>
> I don't really want to expose any functionality that requires a
> customised Maven to run a project, though - that seems like we're
> putting something in that will only be used by you :) It'll likely
> break building other projects using that installation, or not being
> able to build the projects on a different installation (Without
> hints to help). If you're happy using a customised Maven, maybe
> you're best building your own branch off the latest 2.0.x that
> includes the patch?
>
> I'm still all for rolling it onto trunk and putting in example
> projects that let us see this in action and help drive the use
> cases for it going forward.
>
For the branch if it was 100% non-invasive i.e did not interfere at
all with _anything_ setup currently, did not change the default
conflict resolver and was undetectable by the common user, and you
took responsibility and ownership of any problems that arise then I
would be fine with it going into the branch. If you are using the
existing APIs and not changing them _at all_ and just plugging in
your mechanism which works by altering your installation then I don't
see how this will affect any current 2.0.x users. You must also
express this new behavior with ITs and tests as the onus is on you to
make sure we can replicate the behavior but I don't think anyone can
promise anything vis-a-vis the code you use or the ultimate solution
in 2.1.
I can understand not wanting to use 2.1.x and that your solution gets
you where you need to be for 2.0.x. My only concern is that you don't
hose anything currently working. Any sort of conflict resolution
should be declarative and will be the case for 2.1.x. I don't think
it's overly useful in the trunk but put the code into both so they
stay in sync.
I'm fine with the additions as long as you take responsibility for
the changes. You'll have to wait a while as others may not be fine
with it so I'm sure you'll have a clear path this week sometime.
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> 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: [m2] Conflict resolvers
Posted by Brett Porter <br...@apache.org>.
On 22/06/2007, at 8:15 PM, Mark Hobson wrote:
> On 22/06/07, Brett Porter <br...@apache.org> wrote:
>> It's never been an alternative, but it was implemented as "newest
>> wins" in an early alpha.
>
> Curse the person who switched to nearest! ;)
Sorry :(
At the time, the repository data (mostly converted from m1) wasn't
suited to it and you got things you didn't expect. I always expected
you'd be able to turn it on and manage the dependencies properly but
the implementation of that didn't happen.
>
>> > How would anyone select a different strategy? This would require a
>> > change to the POM to even turn on any alternatives. Even if the API
>> > for the resolution was completely hidden something fundamental
>> > would have to change i.e. the POM in order to activate it. No?
>>
>> Yes, I think it'd require a POM change to activate, so I'm more in
>> favour of it being a starting point in 2.1.
>
> As mentioned above, this requires a change in the Maven installation
> rather than the POM. Obviously far from ideal, but I'm happy to live
> with this for the huge gain in productivity.
Can you pull this off through the <extensions> tag in the POM as
Kenney suggested? It seems reasonable, and if so, then I feel a
little more comfortable with it.
I don't really want to expose any functionality that requires a
customised Maven to run a project, though - that seems like we're
putting something in that will only be used by you :) It'll likely
break building other projects using that installation, or not being
able to build the projects on a different installation (Without hints
to help). If you're happy using a customised Maven, maybe you're best
building your own branch off the latest 2.0.x that includes the patch?
I'm still all for rolling it onto trunk and putting in example
projects that let us see this in action and help drive the use cases
for it going forward.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Jun 07, at 3:15 AM 22 Jun 07, Mark Hobson wrote:
> On 22/06/07, Brett Porter <br...@apache.org> wrote:
>> It's never been an alternative, but it was implemented as "newest
>> wins" in an early alpha.
>
> Curse the person who switched to nearest! ;)
>
>> > How would anyone select a different strategy? This would require a
>> > change to the POM to even turn on any alternatives. Even if the API
>> > for the resolution was completely hidden something fundamental
>> > would have to change i.e. the POM in order to activate it. No?
>>
>> Yes, I think it'd require a POM change to activate, so I'm more in
>> favour of it being a starting point in 2.1.
>
> As mentioned above, this requires a change in the Maven installation
> rather than the POM. Obviously far from ideal, but I'm happy to live
> with this for the huge gain in productivity.
>
So how exactly does this help with your situation as I'm looking for
details as I'm loathe to put this in 2.0.x.
> [snip]
>
> 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
Re: [m2] Conflict resolvers
Posted by Kenney Westerhof <ke...@apache.org>.
Mark Hobson wrote:
> On 22/06/07, Brett Porter <br...@apache.org> wrote:
>> It's never been an alternative, but it was implemented as "newest
>> wins" in an early alpha.
>
> Curse the person who switched to nearest! ;)
:)
It should be nearest though, with a fallback to newest if there are 2
nodes at the same depth. I think it's random right now.
>
>> > How would anyone select a different strategy? This would require a
>> > change to the POM to even turn on any alternatives. Even if the API
>> > for the resolution was completely hidden something fundamental
>> > would have to change i.e. the POM in order to activate it. No?
>>
>> Yes, I think it'd require a POM change to activate, so I'm more in
>> favour of it being a starting point in 2.1.
>
> As mentioned above, this requires a change in the Maven installation
> rather than the POM. Obviously far from ideal, but I'm happy to live
> with this for the huge gain in productivity.
Yup, you don't need to change the pom, you can just use either extensions
to plug in alternatives, or use the plugin framework, which is _the_ way
to configure builds, though it doesn't allow for pre-reactor execution atm,
but that could be made to work without pom changes, though i'd favour some plugin
configuration outside the <build> tag for that since this effects resolution
and is not necessarily used by maven to build stuff, but can be used by other applications
to compute a graph.
Basically, use <extensions><extension> and add a <configuration> section to it would work?
Btw, since plugging in alternatives affects the entire graph, I wonder what will
happen if some random module changes the defaults... they're obviously not meant to
apply to the entire graph, but a sub-graph. I can imagine that some transitive dep
would specify a conflicting resolution scheme, and I wonder if that could cause problems.
Perhaps this should/could be reactor-global - add some special commandline parameters to tune
maven, much like the -javaagent args that 'tune' the jvm.
For instance, '--dep-version-conflict-resolution nearest,newest',
which looks for an artifact in a predefined groupId with dep-version-conflict-resolution-<XXX> ?
Or, if we do this in 2.1, we can use the api/impl mechanism in a pom/reactor global way,
outside of build.
Just throwing this out here - it's been discussed offline now and then and we've got
a place reserved for this in the wiki, but there are too much options to choose from
to really write something ;)
-- Kenney
>
> [snip]
>
> Mark
>
> ---------------------------------------------------------------------
> 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: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 22/06/07, Brett Porter <br...@apache.org> wrote:
> It's never been an alternative, but it was implemented as "newest
> wins" in an early alpha.
Curse the person who switched to nearest! ;)
> > How would anyone select a different strategy? This would require a
> > change to the POM to even turn on any alternatives. Even if the API
> > for the resolution was completely hidden something fundamental
> > would have to change i.e. the POM in order to activate it. No?
>
> Yes, I think it'd require a POM change to activate, so I'm more in
> favour of it being a starting point in 2.1.
As mentioned above, this requires a change in the Maven installation
rather than the POM. Obviously far from ideal, but I'm happy to live
with this for the huge gain in productivity.
[snip]
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Brett Porter <br...@apache.org>.
On 22/06/2007, at 11:38 AM, Jason van Zyl wrote:
>
> What alternative have we ever provided?
It's never been an alternative, but it was implemented as "newest
wins" in an early alpha.
>
> How would anyone select a different strategy? This would require a
> change to the POM to even turn on any alternatives. Even if the API
> for the resolution was completely hidden something fundamental
> would have to change i.e. the POM in order to activate it. No?
Yes, I think it'd require a POM change to activate, so I'm more in
favour of it being a starting point in 2.1.
> It's not incompatible at all but it will work completely
> differently with a graph then what's currently there.
Work differently, or be implemented differently? I figured this would
be an opportunity to see how it goes in practice and can help us form
a better spec for 2.1 by having a prototype with some examples to
work with.
Maybe a branch off of trunk is more appropriate.
>
>>> I think everyone agrees that will happen.
>>
>> I don't think we can agree on anything yet, because we haven't
>> formed a proposal.
>
> There are a huge number of details but I don't think any disagrees
> that nothing works unless you start with a graph. It's impossible
> to do anything correctly without that.
>
>> In the few discussions that have happened so far it's clear we're
>> not coming from a common understanding. You said you had something
>> like 6 pages written over a month ago - I think seeing them even
>> in draft form would help us at least be on the same page.
>>
>
> Does anyone disagree we need a graph? I don't think anyone does and
> given that conflict resolution becomes a graph traversal not
> tweaking via a peephole.
Not exactly disagreeing, I just think the devil is in the details for
any discussion we have around this and the more we understand about
where everyone is coming from the better. We've already seen some
concern expressed about the performance of completely pre-calculating
it, I'm currently unsure about some assumptions that might be being
made about version selection.
Nobody disagrees on the fundamental requirements we are trying to
solve, and I'm sure it's expected a graph will be used in some way,
but I don't have enough information to agree that Mark's efforts here
are irrelevant to 2.1.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
On 21 Jun 07, at 6:18 PM 21 Jun 07, Brett Porter wrote:
> On 22/06/2007, at 1:39 AM, Jason van Zyl wrote:
>
>>
>> I don't think this makes sense to add to 2.0.x as we have to 1)
>> provide a way to load these strategies which is taken care of in
>> 2.1, and 2) people will implement them in 2.0.x and then expect
>> them to work in 2.1 which they won't because it will be graph-
>> based in 2.1.
>
> Maybe I misunderstood, but I don't think the intention of this
> patch is to allow other people to plug in their own, but simply
> allowing them to use alternatives we've provided. The pluggable
> part certainly needs to come later.
>
What alternative have we ever provided?
How would anyone select a different strategy? This would require a
change to the POM to even turn on any alternatives. Even if the API
for the resolution was completely hidden something fundamental would
have to change i.e. the POM in order to activate it. No?
> If that's the case, I don't understand why conflict resolution is
> incompatible with being graph based. You still need to make
> decisions at the graph nodes, and the same strategies probably apply.
>
It's not incompatible at all but it will work completely differently
with a graph then what's currently there.
>> I think everyone agrees that will happen.
>
> I don't think we can agree on anything yet, because we haven't
> formed a proposal.
There are a huge number of details but I don't think any disagrees
that nothing works unless you start with a graph. It's impossible to
do anything correctly without that.
> In the few discussions that have happened so far it's clear we're
> not coming from a common understanding. You said you had something
> like 6 pages written over a month ago - I think seeing them even in
> draft form would help us at least be on the same page.
>
Does anyone disagree we need a graph? I don't think anyone does and
given that conflict resolution becomes a graph traversal not tweaking
via a peephole.
>> API exposure, and mechanism for loading the strategies are
>> problems. I don't think it would be wise to promote this at this
>> point in 2.0.x.
>
> I'd actually like to see this committed to trunk. It would give
> people the option to see it in action, and it would mean the future
> solution must be at least as functional. I'm not really big on
> adding features to 2.0.x either, as I've said before.
If anyone disagrees about using a graph then anything can go in trunk
but at a fundamental level I have not seen anything dispute the need
for a graph-based approach including yourself. You cannot do conflict
resolution properly without a graph.
>
> Mark, would this suit you?
>
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> 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: [m2] Conflict resolvers
Posted by Brett Porter <br...@apache.org>.
On 22/06/2007, at 1:39 AM, Jason van Zyl wrote:
>
> I don't think this makes sense to add to 2.0.x as we have to 1)
> provide a way to load these strategies which is taken care of in
> 2.1, and 2) people will implement them in 2.0.x and then expect
> them to work in 2.1 which they won't because it will be graph-based
> in 2.1.
Maybe I misunderstood, but I don't think the intention of this patch
is to allow other people to plug in their own, but simply allowing
them to use alternatives we've provided. The pluggable part certainly
needs to come later.
If that's the case, I don't understand why conflict resolution is
incompatible with being graph based. You still need to make decisions
at the graph nodes, and the same strategies probably apply.
> I think everyone agrees that will happen.
I don't think we can agree on anything yet, because we haven't formed
a proposal. In the few discussions that have happened so far it's
clear we're not coming from a common understanding. You said you had
something like 6 pages written over a month ago - I think seeing them
even in draft form would help us at least be on the same page.
> API exposure, and mechanism for loading the strategies are
> problems. I don't think it would be wise to promote this at this
> point in 2.0.x.
I'd actually like to see this committed to trunk. It would give
people the option to see it in action, and it would mean the future
solution must be at least as functional. I'm not really big on adding
features to 2.0.x either, as I've said before.
Mark, would this suit you?
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Jun 07, at 6:26 AM 22 Jun 07, Jason van Zyl wrote:
>
> MNG-1577 is not simply the employing the nearest strategy of
> selection: it is putting the user in control of what gets selected.
>
>> "To give an example of the number of components within our top-level
>> projects: a typical project has 151 dependencies, 89 of which are
>> internal, and the dependency tree goes up to 7 levels deep. We
>> currently have 25 of these projects, each of which are on differing
>> versions of our internal components. It's easy to see that
>> managing a
>> list of 150 dependency versions across 25 different dependency
>> management sections soon becomes a maintenance nightmare."
>>
>
> For one project you have 25 different depMans?
>
Sorry, pre-coffee. So you are trying to align all your projects that
share no depMap or common parent POM and align the version with a
strategy?
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: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Jun 07, at 6:38 AM 22 Jun 07, Mark Hobson wrote:
>
> "The method I've been using to switch conflict resolvers in 2.0.x
> is by
> supplying an auxiliary components.xml in $M2_HOME/extensions and
> updating m2.conf, as described in MNG-2771. I'm aware that this is
> per-installation and not defined in the POM, but I'm happy to live
> with that for 2.0.x."
>
So what strategy are you using for your disparate builds to align the
versions? What's the strategy you employ?
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: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 22/06/07, Jason van Zyl <ja...@maven.org> wrote:
> On 22 Jun 07, at 2:56 AM 22 Jun 07, Mark Hobson wrote:
> > MNG-1577 is a small step in the right direction, but nearest conflict
> > resolution is the root cause of most of our dependency woes which sap
> > large amounts of developer time. As I mentioned earlier in this
> > thread, our projects consist of many inter-related modules:
>
> MNG-1577 is not simply the employing the nearest strategy of
> selection: it is putting the user in control of what gets selected.
I understand that, but my point was that the overhead of maintaining
dependency management blocks in large projects negates the usefulness
of MNG-1577, so we're still left with nearest-wins problems.
> > "To give an example of the number of components within our top-level
> > projects: a typical project has 151 dependencies, 89 of which are
> > internal, and the dependency tree goes up to 7 levels deep. We
> > currently have 25 of these projects, each of which are on differing
> > versions of our internal components. It's easy to see that managing a
> > list of 150 dependency versions across 25 different dependency
> > management sections soon becomes a maintenance nightmare."
>
> For one project you have 25 different depMans?
Theoretically it would be different depMans across 25 projects. We
don't for obvious reasons, but if we were forced to use depMan to
override the default nearest-wins behaviour then this would be the
situation.
> > The API would be no more exposed than it is now - ConflictResolver is
> > the API and currently already exists in maven-artifact 2.0.x.
>
> Yes, but no one uses it and how are you going to turn it on.
It would be turned on as described above:
"The method I've been using to switch conflict resolvers in 2.0.x is by
supplying an auxiliary components.xml in $M2_HOME/extensions and
updating m2.conf, as described in MNG-2771. I'm aware that this is
per-installation and not defined in the POM, but I'm happy to live
with that for 2.0.x."
> How are you going to activate it?
See above.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Jun 07, at 2:56 AM 22 Jun 07, Mark Hobson wrote:
> On 21/06/07, Jason van Zyl <ja...@maven.org> wrote:
>> I don't think this makes sense to add to 2.0.x as we have to 1)
>> provide a way to load these strategies which is taken care of in 2.1,
>
> The method I've been using to switch conflict resolvers in 2.0.x is by
> supplying an auxiliary components.xml in $M2_HOME/extensions and
> updating m2.conf, as described in MNG-2771. I'm aware that this is
> per-installation and not defined in the POM, but I'm happy to live
> with that for 2.0.x.
>
>> and 2) people will implement them in 2.0.x and then expect them to
>> work in 2.1 which they won't because it will be graph-based in 2.1.
>
> Due to the manual intervention required to switch conflict resolvers,
> I don't think many people will be surprised to have to use a different
> method in 2.1. Conflict resolvers will still be relevant with graph
> based resolution, although I'm sure the API will be slightly
> different.
>
>> I think everyone agrees that will happen. And though the issue has
>> been
>> voted on, how many people are desperate for this now that MNG-1577
>> has been implemented.
>
> MNG-1577 is a small step in the right direction, but nearest conflict
> resolution is the root cause of most of our dependency woes which sap
> large amounts of developer time. As I mentioned earlier in this
> thread, our projects consist of many inter-related modules:
>
MNG-1577 is not simply the employing the nearest strategy of
selection: it is putting the user in control of what gets selected.
> "To give an example of the number of components within our top-level
> projects: a typical project has 151 dependencies, 89 of which are
> internal, and the dependency tree goes up to 7 levels deep. We
> currently have 25 of these projects, each of which are on differing
> versions of our internal components. It's easy to see that managing a
> list of 150 dependency versions across 25 different dependency
> management sections soon becomes a maintenance nightmare."
>
For one project you have 25 different depMans?
>> Technically this is not a problem. The problem is exposing the API
>> near the end of 2.0.x active development and then having to support
>> this later on.
>
> The API would be no more exposed than it is now - ConflictResolver is
> the API and currently already exists in maven-artifact 2.0.x.
Yes, but no one uses it and how are you going to turn it on.
> The
> patch merely supplies alternative implementations of this API and uses
> it as intended in DefaultArtifactCollector. Thus the API is no more
> exposed than any other Plexus component within Maven.
>
>> API exposure, and mechanism for loading the strategies are problems.
>> I don't think it would be wise to promote this at this point in
>> 2.0.x.
>
> I've covered both of these points above. It would be shame to deny
> 2.0.x this much-needed feature and force users to wait months,
> possibly a year, for a stable 2.1. I'd be forced to maintain a
> patched version of 2.0.x since we desperately need this now.
>
How are you going to activate it?
> 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
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 21/06/07, Jason van Zyl <ja...@maven.org> wrote:
> I don't think this makes sense to add to 2.0.x as we have to 1)
> provide a way to load these strategies which is taken care of in 2.1,
The method I've been using to switch conflict resolvers in 2.0.x is by
supplying an auxiliary components.xml in $M2_HOME/extensions and
updating m2.conf, as described in MNG-2771. I'm aware that this is
per-installation and not defined in the POM, but I'm happy to live
with that for 2.0.x.
> and 2) people will implement them in 2.0.x and then expect them to
> work in 2.1 which they won't because it will be graph-based in 2.1.
Due to the manual intervention required to switch conflict resolvers,
I don't think many people will be surprised to have to use a different
method in 2.1. Conflict resolvers will still be relevant with graph
based resolution, although I'm sure the API will be slightly
different.
> I think everyone agrees that will happen. And though the issue has been
> voted on, how many people are desperate for this now that MNG-1577
> has been implemented.
MNG-1577 is a small step in the right direction, but nearest conflict
resolution is the root cause of most of our dependency woes which sap
large amounts of developer time. As I mentioned earlier in this
thread, our projects consist of many inter-related modules:
"To give an example of the number of components within our top-level
projects: a typical project has 151 dependencies, 89 of which are
internal, and the dependency tree goes up to 7 levels deep. We
currently have 25 of these projects, each of which are on differing
versions of our internal components. It's easy to see that managing a
list of 150 dependency versions across 25 different dependency
management sections soon becomes a maintenance nightmare."
> Technically this is not a problem. The problem is exposing the API
> near the end of 2.0.x active development and then having to support
> this later on.
The API would be no more exposed than it is now - ConflictResolver is
the API and currently already exists in maven-artifact 2.0.x. The
patch merely supplies alternative implementations of this API and uses
it as intended in DefaultArtifactCollector. Thus the API is no more
exposed than any other Plexus component within Maven.
> API exposure, and mechanism for loading the strategies are problems.
> I don't think it would be wise to promote this at this point in 2.0.x.
I've covered both of these points above. It would be shame to deny
2.0.x this much-needed feature and force users to wait months,
possibly a year, for a stable 2.1. I'd be forced to maintain a
patched version of 2.0.x since we desperately need this now.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
On 21 Jun 07, at 2:55 AM 21 Jun 07, Mark Hobson wrote:
> On 18/05/07, Brett Porter <br...@apache.org> wrote:
>> As it turned out, we didn't talk about the artifact resolution
>> mechanism in great detail. Jason told us he is working on a paper to
>> describe how it might be re-implemented in 2.1.
>>
>> Jason, any chance you could push what you have into SVN so we can
>> provide some feedback and see how it might line up with Mark's work?
>> If it is compatible, and the patch is good, then we could apply that
>> to trunk now.
>>
>> Either way, I don't think applying this on 2.0.x is a good move. We
>> have to draw the line about new features getting added there.
>
> I'd like to reach a consensus on whether we can include MNG-612 in
> 2.0.8. It's currently scheduled for 2.1.x, which means that it will
> be superseded by the dependency graph code we've been discussing on
> another thread. It's also a long way off, since this is still in the
> specification stage and no code has been committed yet.
>
I don't think this makes sense to add to 2.0.x as we have to 1)
provide a way to load these strategies which is taken care of in 2.1,
and 2) people will implement them in 2.0.x and then expect them to
work in 2.1 which they won't because it will be graph-based in 2.1. I
think everyone agrees that will happen. And though the issue has been
voted on, how many people are desperate for this now that MNG-1577
has been implemented.
> The patch attached to MNG-612 works with the current 2.0.x
> architecture and simply makes the conflict resolver pluggable, rather
> than hardcoded as it is now.
Technically this is not a problem. The problem is exposing the API
near the end of 2.0.x active development and then having to support
this later on.
> This issue has 13 votes which, if
> targeted for 2.0.x, would make it the third most voted for issue for
> 2.0.x. Seeing as the patch is pretty non-destructive and the work is
> ready to go, are there any good reasons to veto MNG-612 being included
> in 2.0.8?
>
API exposure, and mechanism for loading the strategies are problems.
I don't think it would be wise to promote this at this point in 2.0.x.
> 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
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 18/05/07, Brett Porter <br...@apache.org> wrote:
> As it turned out, we didn't talk about the artifact resolution
> mechanism in great detail. Jason told us he is working on a paper to
> describe how it might be re-implemented in 2.1.
>
> Jason, any chance you could push what you have into SVN so we can
> provide some feedback and see how it might line up with Mark's work?
> If it is compatible, and the patch is good, then we could apply that
> to trunk now.
>
> Either way, I don't think applying this on 2.0.x is a good move. We
> have to draw the line about new features getting added there.
I'd like to reach a consensus on whether we can include MNG-612 in
2.0.8. It's currently scheduled for 2.1.x, which means that it will
be superseded by the dependency graph code we've been discussing on
another thread. It's also a long way off, since this is still in the
specification stage and no code has been committed yet.
The patch attached to MNG-612 works with the current 2.0.x
architecture and simply makes the conflict resolver pluggable, rather
than hardcoded as it is now. This issue has 13 votes which, if
targeted for 2.0.x, would make it the third most voted for issue for
2.0.x. Seeing as the patch is pretty non-destructive and the work is
ready to go, are there any good reasons to veto MNG-612 being included
in 2.0.8?
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Brett Porter <br...@apache.org>.
As it turned out, we didn't talk about the artifact resolution
mechanism in great detail. Jason told us he is working on a paper to
describe how it might be re-implemented in 2.1.
Jason, any chance you could push what you have into SVN so we can
provide some feedback and see how it might line up with Mark's work?
If it is compatible, and the patch is good, then we could apply that
to trunk now.
Either way, I don't think applying this on 2.0.x is a good move. We
have to draw the line about new features getting added there.
Thanks!
- Brett
On 17/05/2007, at 10:06 AM, Mark Hobson wrote:
> On 30/04/07, Brett Porter <br...@apache.org> wrote:
>> As Mark further explained, I think his proposal is entirely different
>> and could be adapted to whatever strategy you apply in general here.
>
> Was there any consensus on whether to apply MNG-612 to 2.0.x after all
> the conferences?
>
> Mark
>
> ---------------------------------------------------------------------
> 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: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
On 30/04/07, Brett Porter <br...@apache.org> wrote:
> As Mark further explained, I think his proposal is entirely different
> and could be adapted to whatever strategy you apply in general here.
Was there any consensus on whether to apply MNG-612 to 2.0.x after all
the conferences?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Brett Porter <br...@apache.org>.
As Mark further explained, I think his proposal is entirely different
and could be adapted to whatever strategy you apply in general here.
However, I wanted to pick up on this:
On 25/04/2007, at 2:36 PM, Jason van Zyl wrote:
> 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.
Agreed. The case today is probably more a problem of premature
optimisation (reading the whole graph when you are going to throw
things away is time consuming when you need to download all the
associated poms). So reading the whole graph then applying conflict
resolvers, etc. is a better strategy - though it may require we work
more on the metadata to make it less messy.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Barrie Treloar <ba...@gmail.com>.
On 4/25/07, Jason van Zyl <ja...@maven.org> wrote:
> 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.
I have yet to raise this in JIRA,
but could Artifact include the repository it came from?
At the moment Artifact resolution uses the last repository an Artifact
was found in, not the repository that is located in the resolved
Artifact.
This is an edge case, but it affects the way I have chosen to provide
internal patches to artifacts. I am only bumping the versionId (as
changing the groupId is an invasive change)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Mark Hobson <ma...@gmail.com>.
Hi Jason,
Thanks for the reply. I was following the MNG-1577 debate and agree
that this is certainly a step in the right direction. The dependency
management solution is suitable for smaller projects with a manageable
set of transitive dependencies, although it starts to grow unwieldy
with larger projects and begins to resemble M1's flattened list of
dependencies.
To give an example of the number of components within our top-level
projects: a typical project has 151 dependencies, 89 of which are
internal, and the dependency tree goes up to 7 levels deep. We
currently have 25 of these projects, each of which are on differing
versions of our internal components. It's easy to see that managing a
list of 150 dependency versions across 25 different dependency
management sections soon becomes a maintenance nightmare.
Ultimately we intend to use newest-wins conflict resolution in
combination with ranges once MRELEASE-177 is fixed. This should
resolve the problem of conflict resolution upgrading transitive
dependencies to incompatible versions. Even in the case where ranges
are not being used, I find nearest-wins conflict resolution so
arbitrary when working on projects with a large dependency tree.
We've spent hours digging through dependency trees after encountering
runtime linking errors.
I do like the notion of applying a chain of transformers to the fully
parsed dependency graph, although I assume this would be targeted for
2.1? We've been using 2.0 since the early alphas and are now enjoying
a degree of stability, so I'd rather not move to 2.1 until it becomes
final. The MNG-612 patch preserves the current nearest-wins conflict
resolution, but allows the implementation to be changed for those who
require it. I would have thought this would be a good compromise for
the 2.0.x branch until 2.1 supersedes it?
Cheers,
Mark
On 25/04/07, Jason van Zyl <ja...@maven.org> wrote:
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] Conflict resolvers
Posted by Jason van Zyl <ja...@maven.org>.
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: 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