[MNG-5214] Dependency resolution substitutes g:a:v:jar for j:a:v:something-else when something-else isn't in the reactor

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.0
• Fix Version/s: 3.1.0-alpha-1
• Component/s: Dependencies
• Assignee: Jason van Zyl
• Reporter: Benson Margulies
• Created: 07/Dec/11 16:44
• Updated: 07/Apr/15 12:24
• Resolved: 19/Jan/14 14:12

Description

Start with:

https://svn.apache.org/repos/asf/cxf/trunk

Put some pergem space into MAVEN_OPTS (http://cxf.apache.org/building.html)

run mvn -Pfastinstall

Now, cd to systests/wsdl_maven

Run mvn site:site

Here's what's happening under the covers. The first child module has an execution of the CXF java2ws plugin in 'process-classes'. The second module has an execution of the CXF codegen plugin in 'generate-sources'.

The first module creates, and attaches, an artifact: org.apache.cxf.systests.wsdl_maven:cxf-systests-java2ws:(v):wsdl.
The second module declares it as a dependency.

In a multi-module project, one module has a plugin execution in phase 'process-classes' that produces an attached artifact (with type 'wsdl').

The site lifecycle does not, by default, include process-classes. So the wsdl isn't in the reactor, but it's cousin the 'jar' is.

When the codegen plugin calls the artifact resolver, it expects to get an error, or, better yet, a copy of that wsdl from the local repo or the apache snapshot repo. Instead, the resolver 'resolves' the artifact to the corresponding 'jar' in the reactor. Calling getFile() returns the target/classes directory.

Issue Links

• relates to: MNG-5503 Maven 3.1.0 fails to resolve artifacts produced by reactor build