On 11/19/2010 01:36 PM, Rex Hoffman wrote:
Maybe we should construct a cleaner api though. One that could wrap maven-dependency-tree in maven 2.2.1 and use aether in 3.0.
Alternately: release maven-dependency-tree 1.3 with an unchanged public signature that is just a proxy for Aether API, and mark m-d-p deprecated (i.e. new code should use Aether directly). This would allow clients such as the dependency plugin to easily and immediately fix the visible bug (inconsistency with Aether's resolution), and switch to the preferred API when time permits. aether-api has no dependencies so it should not be burdensome to include it as a transitive dep of m-d-t 1.3 from an existing client, even a plugin running in Maven 2, but perhaps aether-impl also would need to be included with runtime scope.
The question is whether you *want* something like the dependency plugin when running in M2 to mimic the graph traversal bugs in M2, or whether you want it to behave like the corrected version in M3. If the former, then a related possibility is to have m-d-t 1.3 behave like 1.2 did (using the same old code), unless an optional component is present which depends on Aether and switches the behavior to mimic M3. This would only work for plugins in case they could express a runtime dependency on a certain artifact iff running inside M3.
I don't pretend to understand m-d-p very deeply, but I have a bunch of old code (not written by me) which uses it, and my attempts to switch to org.sonatype.aether.graph were foiled by the fact that there is not a clear correspondence between the APIs when you get into the details. In particular, there is no apparent equivalent to DependencyNode.getState, and some of my client code has explicit handling of e.g. OMITTED_FOR_CONFLICT which is central to its function.
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
