You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Andrew Lee Rubinger <al...@jboss.org> on 2008/10/30 06:50:31 UTC
Status of ConflictResolver SPI
Asking here on the dev-list because I would like to contribute to any of
the points below if unaddressed.
What is the current status of the ConflictResolver SPI as outlined in:
* http://docs.codehaus.org/display/MAVEN/Conflict+Resolvers
* http://www.nabble.com/-m2--Conflict-resolvers-td10144607i40.html
...?
The issue is tracked as open in:
http://jira.codehaus.org/browse/MNG-612
Additionally, I'm not seeing a "FailFastConflictResolver" in
org.apache.maven.artifact.resolver, the purpose of which would be to
immediately fail the build if two projects bring in transitive
dependencies of different versions. Perhaps this is because conflict
resolvers are based on a chain implementation, and it's not the resolver
itself which has authority to fail a build (ie. can just return null and
delegate to the next resolver in the chain)?
Some related questions:
* Is support here planned to be backported into 2.0.x or 2.1.x? I do
see some year-old commits into
https://svn.apache.org/repos/asf/maven/components/branches/MNG-612-2.0.x/,
for example.
* Is there a publicly-viewable roadmap for 3.0 with time estimates?
* I see ConflictResolver unit tests to check for proper resolution, but
no examples of a POM configuring an explicit ConflictResolver set?
We've moved our build implementation heavily to Maven over at JBoss
within the Application Server, and I'd like to help augment Maven to fit
our needs.
Appreciated. :)
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss EJB3
JBoss, a division of Red Hat, Inc.
http://www.jboss.org/jbossejb3/
http://exitcondition.alrubinger.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Status of ConflictResolver SPI
Posted by Oleg Gusakov <ol...@gmail.com>.
Mark Hobson wrote:
>
> I haven't pursued this of recent since there was talk of overhauling
> maven-artifact and the whole dependency resolution mechanism in
> general with Mercury:
>
> http://docs.codehaus.org/display/MAVEN/Mercury
>
> AFAIK Mercury will supersede MNG-612 and provide customisable conflict
> resolvers, although I am not aware of the details. Perhaps Oleg could
> confirm this and put both our minds at rest? :)
>
>
>
You can safely put your minds at rest guys :)
Mercury is a customizable conflict resolver in a sense that:
- it's a standalone library with no Maven dependencies
- you can supply your own dependency provider - it does not depend on
POM files. Shane wrote an adaptor for ProjectBuilder which reads POMs
- it still operates on GAV model, so all the benefits/problems apply
- SNAPSHOT, RELEASE, LATEST are supported
- it implemented OSGi standard version ranges
- single version behavior is configurable: can be either x=1.2.3 by
default, or could be x>=1.2.3 with an option
- version range interpreter could be replaced - as it's an interface
- SAT conflict resolver itself is hardwired for now, but I can
externalize it as well
Dis I answer all questions? Ask more :)
Thanks,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Status of ConflictResolver SPI
Posted by Mark Hobson <ma...@gmail.com>.
Hi Andrew,
2008/10/30 Andrew Lee Rubinger <al...@jboss.org>:
> Asking here on the dev-list because I would like to contribute to any of the
> points below if unaddressed.
>
> What is the current status of the ConflictResolver SPI as outlined in:
>
> * http://docs.codehaus.org/display/MAVEN/Conflict+Resolvers
> * http://www.nabble.com/-m2--Conflict-resolvers-td10144607i40.html
>
> ...?
>
> The issue is tracked as open in:
>
> http://jira.codehaus.org/browse/MNG-612
Good question :) I started this a long time ago when we required more
sophisticated conflict resolution than nearest-wins but unfortunately
it has never made it into a release of Maven, although it has been
applied to the new separate maven-artifact 3.x which Maven trunk (3.x)
uses.
I haven't pursued this of recent since there was talk of overhauling
maven-artifact and the whole dependency resolution mechanism in
general with Mercury:
http://docs.codehaus.org/display/MAVEN/Mercury
AFAIK Mercury will supersede MNG-612 and provide customisable conflict
resolvers, although I am not aware of the details. Perhaps Oleg could
confirm this and put both our minds at rest? :)
> Additionally, I'm not seeing a "FailFastConflictResolver" in
> org.apache.maven.artifact.resolver, the purpose of which would be to
> immediately fail the build if two projects bring in transitive dependencies
> of different versions. Perhaps this is because conflict resolvers are based
> on a chain implementation, and it's not the resolver itself which has
> authority to fail a build (ie. can just return null and delegate to the next
> resolver in the chain)?
It is true that a single conflict resolver cannot fail-fast with the
current API, although in reality I'd suspect that a chain of resolvers
would rarely be used. Perhaps something to consider for the new
Mercury API?
> Some related questions:
>
> * Is support here planned to be backported into 2.0.x or 2.1.x? I do see
> some year-old commits into
> https://svn.apache.org/repos/asf/maven/components/branches/MNG-612-2.0.x/,
> for example.
> * Is there a publicly-viewable roadmap for 3.0 with time estimates?
This won't be added to 2.0.x since that line is stable with only bug
fixes being applied. I'd rather see efforts applied to integrate
Mercury into Maven if this truly supersedes MNG-612. This could be a
possibility for 2.1.x but I believe it's currently targeted for 2.2.x:
http://docs.codehaus.org/display/MAVEN/Maven+2.2.0+Release+Plan
http://jira.codehaus.org/browse/MERCURY-11
> * I see ConflictResolver unit tests to check for proper resolution, but no
> examples of a POM configuring an explicit ConflictResolver set?
Nope, I don't believe there are any integration tests for MNG-612 yet
due to its in limbo status.
> We've moved our build implementation heavily to Maven over at JBoss within
> the Application Server, and I'd like to help augment Maven to fit our needs.
Yep, we're eager to start using fail-fast highest-wins version ranges
ASAP here too. Hopefully it's not too far away now thanks to all
Oleg's hard work..
> Appreciated. :)
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org