You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Benson Margulies (JIRA)" <ji...@codehaus.org> on 2011/12/07 23:46:39 UTC
[jira] Created: (MSITE-623) lifecycle dependency failure with code
generation versus javadocs versus the site plugin
lifecycle dependency failure with code generation versus javadocs versus the site plugin
----------------------------------------------------------------------------------------
Key: MSITE-623
URL: https://jira.codehaus.org/browse/MSITE-623
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: Maven 3
Affects Versions: 3.0
Reporter: Benson Margulies
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?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[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
Posted by "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
[jira] Closed: (MNG-5214) Dependency resolution substitutes
g:a:v:jar for j:a:v:something-else when something-else isn't in the reactor
Posted by "Benson Margulies (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benson Margulies closed MNG-5214.
---------------------------------
Resolution: Fixed
Fix Version/s: 3.0.5
Assignee: Benson Margulies
I seem to have fixed it.
> 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
> Assignee: Benson Margulies
> Fix For: 3.0.5
>
>
> 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
[jira] Commented: (MNG-5214) Dependency resolution substitutes
g:a:v:jar for j:a:v:something-else when something-else isn't in the reactor
Posted by "Benson Margulies (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285353#comment-285353 ]
Benson Margulies commented on MNG-5214:
---------------------------------------
Here's a backtrace of the artifact being resolved inappropriately.
DefaultArtifact.setFile(File) line: 202
RepositoryUtils.toArtifact(Artifact) line: 96
RepositoryUtils.toArtifact(Dependency) line: 69
RepositoryUtils.toArtifacts(Collection<Artifact>, Collection<DependencyNode>, List<String>, DependencyFilter) line: 112
LifecycleDependencyResolver.getDependencies(MavenProject, Collection<String>, Collection<String>, MavenSession, boolean, Set<Artifact>) line: 219
LifecycleDependencyResolver.resolveProjectDependencies(MavenProject, Collection<String>, Collection<String>, MavenSession, boolean, Set<Artifact>) line: 117
MojoExecutor.ensureDependenciesAreResolved(MojoDescriptor, MavenSession, DependencyContext) line: 258
MojoExecutor.execute(MavenSession, MojoExecution, ProjectIndex, DependencyContext) line: 201
MojoExecutor.execute(MavenSession, MojoExecution, ProjectIndex, DependencyContext, PhaseRecorder) line: 153
MojoExecutor.execute(MavenSession, List<MojoExecution>, ProjectIndex) line: 145
MojoExecutor.executeForkedExecutions(MojoExecution, MavenSession, ProjectIndex) line: 365
DefaultLifecycleExecutor.executeForkedExecutions(MojoExecution, MavenSession) line: 173
DefaultMavenReportExecutor.buildReportPlugin(MavenReportExecutorRequest, ReportPlugin, List<String>, List<MavenReportExecution>) line: 282
DefaultMavenReportExecutor.buildMavenReports(MavenReportExecutorRequest) line: 148
> 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
[jira] Commented: (MNG-5214) Dependency resolution substitutes
g:a:v:jar for j:a:v:something-else when something-else isn't in the reactor
Posted by "Benson Margulies (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285360#comment-285360 ]
Benson Margulies commented on MNG-5214:
---------------------------------------
/Users/benson/asf/mvn/maven-3 svn log -r1212564
------------------------------------------------------------------------
r1212564 | bimargulies | 2011-12-09 13:30:26 -0500 (Fri, 09 Dec 2011) | 7 lines
MNG-5214: Dependency resolution substitutes g:a:v:jar for j:a:v:something-else when something-else isn't in the reacto
o When Aether asks the ReactorReader for a file for an artifact, remember to match type and classifier. And if all else
fails, do not return target/classes if the desired artifact is not of type 'jar'. Arguably, if type or classifier
are non-default, then we should never return those default paths at all.
o Add 'dir' format to make it quicker to run a quick test. If everyone hates this I'll revert it.
------------------------------------------------------------------------
> 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
> Assignee: Benson Margulies
> Fix For: 3.0.5
>
>
> 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
[jira] Reopened: (MNG-5214) Dependency resolution substitutes
g:a:v:jar for j:a:v:something-else when something-else isn't in the reactor
Posted by "Benson Margulies (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benson Margulies reopened MNG-5214:
-----------------------------------
> 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
> Assignee: Benson Margulies
> Fix For: 3.0.5
>
>
> 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
[jira] Commented: (MSITE-623) lifecycle dependency failure with
code generation versus javadocs versus the site plugin
Posted by "Benson Margulies (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MSITE-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285198#comment-285198 ]
Benson Margulies commented on MSITE-623:
----------------------------------------
This is actually a Maven 3 core bug. Until I figure out where to really put this report, I',m leaving it parked here.
> lifecycle dependency failure with code generation versus javadocs versus the site plugin
> ----------------------------------------------------------------------------------------
>
> Key: MSITE-623
> URL: https://jira.codehaus.org/browse/MSITE-623
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: Maven 3
> Affects Versions: 3.0
> Reporter: Benson Margulies
>
> 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?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-623) lifecycle dependency failure with
code generation versus javadocs versus the site plugin
Posted by "Benson Margulies (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MSITE-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285212#comment-285212 ]
Benson Margulies commented on MSITE-623:
----------------------------------------
I don't see how. This one is only in M3, not M2.2.1. It's really not a site thing at all. I believe that the bug is shaped as follows:
If you ask the artifact resolver API for g:a:v:wsdl, and that isn't in the reactor, but g:a:v:jar is in the reactor, you get g:a:b:jar instead of searching repos or nuthin.
> lifecycle dependency failure with code generation versus javadocs versus the site plugin
> ----------------------------------------------------------------------------------------
>
> Key: MSITE-623
> URL: https://jira.codehaus.org/browse/MSITE-623
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: Maven 3
> Affects Versions: 3.0
> Reporter: Benson Margulies
>
> 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?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5214) Dependency resolution substitutes
g:a:v:jar for j:a:v:something-else when something-else isn't in the reactor
Posted by "Benson Margulies (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285355#comment-285355 ]
Benson Margulies commented on MNG-5214:
---------------------------------------
Got it.
public File findArtifact( Artifact artifact )
{
String projectKey = ArtifactUtils.key( artifact.getGroupId(), artifact.getArtifactId(), artifact.getVersion() );
MavenProject project = projectsByGAV.get( projectKey );
if ( project != null )
{
File file = find( project, artifact );
if ( file == null && project != project.getExecutionProject() )
{
file = find( project.getExecutionProject(), artifact );
}
return file;
}
return null;
}
This is a recipe for disaster.
> 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
[jira] Commented: (MNG-5214) Dependency resolution substitutes
g:a:v:jar for j:a:v:something-else when something-else isn't in the reactor
Posted by "Benson Margulies (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285358#comment-285358 ]
Benson Margulies commented on MNG-5214:
---------------------------------------
The problem here is in ReactorReader, which is very willing to return things of the wrong type.
> 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
[jira] (MNG-5214) Dependency resolution substitutes g:a:v:jar for
j:a:v:something-else when something-else isn't in the reactor
Posted by "Benson Margulies (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benson Margulies closed MNG-5214.
---------------------------------
Resolution: Fixed
Now there's a full integration test that fails before this fix and works after.
> 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
> Assignee: Benson Margulies
> Fix For: 3.0.5
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MNG-5214) lifecycle dependency failure with code
generation versus javadocs versus the site plugin
Posted by "Benson Margulies (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benson Margulies moved MSITE-623 to MNG-5214:
---------------------------------------------
Complexity: Intermediate
Component/s: (was: Maven 3)
Dependencies
Affects Version/s: (was: 3.0)
3.0
Key: MNG-5214 (was: MSITE-623)
Project: Maven 2 & 3 (was: Maven 2.x and 3.x Site Plugin)
> lifecycle dependency failure with code generation versus javadocs versus the site plugin
> ----------------------------------------------------------------------------------------
>
> 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
>
> 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?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-623) lifecycle dependency failure with
code generation versus javadocs versus the site plugin
Posted by "Lukas Theussl (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MSITE-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285204#comment-285204 ]
Lukas Theussl commented on MSITE-623:
-------------------------------------
Seems related to MSITE-171?
> lifecycle dependency failure with code generation versus javadocs versus the site plugin
> ----------------------------------------------------------------------------------------
>
> Key: MSITE-623
> URL: https://jira.codehaus.org/browse/MSITE-623
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: Maven 3
> Affects Versions: 3.0
> Reporter: Benson Margulies
>
> 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?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira