[
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
