IMHO, whatever we do, we need to be able to write plugins that work with Maven 2 and Maven 3.0.x and 3.1 and 3.2 and...: that's my key objective
Then I found a solution in maven-dependency-tree (or at least that's the intent): create a thin layer that maps to the past internal 2.x and 3.0.x APIs (3.0.x internal API being Sonatype Aether), and that will map to future APIs whatever they are DefaultDependencyGraphBuilder does the necessary woodoo to detect which version of Maven is running, then use the right DependencyGraphBuilder implementation, that uses the corresponding API used by Maven internals. I already wrote a wrapper for Eclipse Aether in r1398039/MSHARED-250, with a siwtch in DefaultDependencyGraphBuilderin based on the detection of org.eclipse.aether.artifact.Artifact class I don't really know what "use Aether's APIs directly or not" means. I see 2 places: 1. Maven core, that use Aether API in its internal, and I don't see it much as a problem when it is kept an internal implementation detail and doesn't leak in public API - or not too much, "too much" being vague: the minimum is what is necessary to be used by maven-dependency-tree 2. plugins or components: using Aether API would mean that it won't work with Maven 2 or 3.0. With maven-dependency-tree layer as compatibility layer, the problem disappears. But DependencyGraphBuilder API is rather limited: any feature requiring an extension to this API would require to implement it for Maven 2 + 3.0 + 3.1 + ... For example, as Karl found recently, the actual DependencyGraphBuilder removed conflict reporting (which was available for Maven 2 but not Maven 3.0, then got removed from abstract layer). We're actually working to get the feature for Maven 3.0, then add it to the abstract layer. So, to me, we should be able to switch Maven core to use Eclipse Aether instead of Sonatype Aether and use maven-dependency-tree in components and plugins without much problems. The only thing that require special attention is knowing how much Eclipse Aether is different from Sonatype Aether, package change taken apart Regards, Hervé Le samedi 10 novembre 2012 14:42:50 Jason van Zyl a écrit : > Hi, > > I can't honestly tell whether the decision was made to use Aether's APIs > directly or not. I made some less liberal changes because I thought that we > were not going to use the Aether APIs directly because John wanted to > create a new API and Mark seemed vehemently opposed to using them directly. > Since then Hérve has integrated the Aether APIs directly into the > dependency plugins instead of extending the Maven Artifact APIs and using > those. So I'm not sure where the decision was ever made to strictly not use > the Aether APIs or if the decision changed or what. > > The precedent seems to have been set by Hérve that we are using them, I just > want to make sure we're all in agreement. I honestly don't think there is > much value in creating another API because it's hard and I don't believe > anyone has the time to replicate what Benjamin did. > > What is everyone thinking now? > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > believe nothing, no matter where you read it, > or who has said it, > not even if i have said it, > unless it agrees with your own reason > and your own common sense. > > -- Buddha --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
