[
http://jira.codehaus.org/browse/MPIR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gregg Yost updated MPIR-144:
----------------------------
Attachment: MPIR-144-example2.zip
This contains the files referenced in Gregg Yost (gyost)'s comment entered on
October 30, 2008.
> Dependency report introduces corruption in classpaths for other plugins
> -----------------------------------------------------------------------
>
> Key: MPIR-144
> URL: http://jira.codehaus.org/browse/MPIR-144
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
> Affects Versions: 2.1
> Environment: Maven version: 2.0.8
> Java version: 1.5.0_11
> OS name: "linux" version: "2.6.9-42.elsmp" arch: "i386" Family: "unix" (RHEL
> 4)
> Reporter: Robert Golkosky
> Priority: Critical
> Attachments: failure-run.log,
> maven-project-info-report-defect.tar.gz, MPIR-144-example2.zip,
> successful-run.log
>
>
> When enabling the dependency report of the project info reports plugin and
> generating the site for a multi-module project, it appears that the
> classpaths being constructed for the compile and surefire plugins are being
> altered. This only occurs when the dependency report is enabled, i.e. the
> build succeeds and the site can be generated without the dependency report
> enabled.
> I've attached a simple maven project which demonstrates the failure. You can
> observe the successful build by running "mvn clean install site:site", and
> the failure scenario by enabling the profile "projectReports": mvn clean
> install site:site -P projectReports. You can also find debug logs attached
> for both a successful build and a failed build.
> The build failure is caused by improperly adding the test jar artifact for
> project-a to the testCompile classpath of project-c. In the successful build
> scenario, project-c will receive the primary project-a jar artifact
> transitively through interface-b. Even more interesting is the fact that if
> project-c includes a direct dependency on project-a, the test jar artifact
> will still be added to the classpath. One final note about the sample
> project, removing the dependency from project-c to project-b has no impact on
> the build failure, but removing project-b from the reactor (i.e. comment out
> the project-b module from the main pom.xml) will cause the failure to go away.
> This problem does not occur with version 2.0.1 of the project info reports
> plugin. I also tried Maven 2.1-M1 to see if the problem might be resolved
> there, but the classpath corruption still occurs.
> The root cause of this problem may actually lie in a shared component like
> maven-dependency-tree, but I found it originally through the use of the
> project info reports plugin so I figured this would be a good place to start
> tracking it down.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
