Fix for issue 350

[william-ferguson-au]

Can now support Wagon extensions like the s3wagon when resolving dependencies at start of build (necessary to handle AAR dependencies correctly)

[william-ferguson-au]

NB the maven-dependency-tree-2.2-SNAPSHOT should now be available from the Apache SNAPSHOT repository.

[william-ferguson-au]

HOLD - For some reason MavenSession.getTopLevelProject().getClassRealm() is returning null in AMP when it doesn't in https://github.com/william-ferguson-au/example-resolution-plugin/tree/switch-classloader

[malachid]

Do we need a specific set of pull requests to help troubleshoot this?

[william-ferguson-au]

Just base AMP + this pull request highlights problem.

[malachid]

ok, using resolving-reactor-deps-4 and this PR, plugin built then against my test project I see your NPE in: at org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.canFindCoreClass(DefaultDependencyGraphBuilder.java:119)

look right?

[william-ferguson-au]

Yep, that's the failure I am seeing.
I don't think AMP is being configured correctly.

[malachid]

The core class it is trying to load is org.eclipse.aether.artifact.Artifact but the context class loader is null.

[william-ferguson-au]

?? What do you mean? What core class? eclipse.aether will be loaded if you are running Maven-3.1+

[malachid]

The NPE on line 119 is:
Thread.currentThread().getContextClassLoader().loadClass( className );
I broke that into a couple lines and rebuilt.
during the NPE, className = "org.eclipse.aether.artifact.Artifact" and the classloader is null.

[william-ferguson-au]

Yeah. The problem is that the Thread CCL is null. Which is because MavenSession#topLevelProject#classRealm is null.
Leave it with me, I am a long way down this rabbit hole.

[mosabua]

Comment here if its ready to be pulled in..

[william-ferguson-au]

I feel like I'm getting close but may not be able to get back to it until
Friday night. It is failing for some builds and not others. Interestingly
the example-resolution-plugin works for those builds for which AMP is
failing.

So I am trying to narrow the distance between the too to work out the
discrepancy.

On Thu, May 22, 2014 at 8:24 AM, Manfred Moser notifications@github.comwrote:

Comment here if its ready to be pulled in..

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/361#issuecomment-43822339
.

[mosabua]

I am pulling this in so we have a common base again ...

[william-ferguson-au]

Fair call. Are we able (or should we) to take maven-dependency-tree from Apache snapshots now? Maybe add a temporary repository to our pom?

[mosabua]

Have you talked to Herve about releasing it?

[william-ferguson-au]

No. I think he believes that another implementation is possible and is looking into that (basically the code he showed me suggests that the DependencyResolver should already have been finding the snapshots, so it's a question of why it wasn't working in the first place).

Aren't the Apache snapshots released automatically once the code is committed?

[william-ferguson-au]

I'm just looking for a way that everyone can build straight off the AMP master without having to first build my MDT branch. Common base etc.