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

["Benson Margulies (JIRA)" <ji...@codehaus.org>]

     [ https://jira.codehaus.org/browse/MNG-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benson Margulies updated MNG-5214:
----------------------------------

          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.



  was:
This is related to MSITE-622.

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

A second module depends on it, and has another plugin execution in phase 'generate-sources' that depends on the artifact from the first one.

The second project declares this dependency.

When I run site:site, it does not run compile, or process-classes, so the wsdl artifact is not in the reactor, and then the second plugin can't find it, and the build fails (and, as per -622, no explanation is shown without -X). (That's particularly odd, since it should be sitting in the local repo from a previous build.)

How is something like this supposed to work?



    Testcase included: yes
              Summary: Dependency resolution substitutes g:a:v:jar for j:a:v:something-else when something-else isn't in the reactor  (was: lifecycle dependency failure with code generation versus javadocs versus the site plugin)

> Dependency resolution substitutes g:a:v:jar for j:a:v:something-else when something-else isn't in the reactor
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: MNG-5214
>                 URL: https://jira.codehaus.org/browse/MNG-5214
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Dependencies
>    Affects Versions: 3.0
>            Reporter: Benson Margulies
>
> 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.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira