You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Robert Golkosky (JIRA)" <ji...@codehaus.org> on 2008/10/07 23:23:08 UTC
[jira] Created: (MPIR-144) Dependency report introduces corruption
in classpaths for other plugins
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, 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
[jira] Updated: (MPIR-144) Dependency report introduces corruption
in classpaths for other plugins
Posted by "Gregg Yost (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Commented: (MPIR-144) Dependency report introduces
corruption in classpaths for other plugins
Posted by "Gregg Yost (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MPIR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152491#action_152491 ]
Gregg Yost commented on MPIR-144:
---------------------------------
I'm having a similar but somewhat different problem involving classpath corruption when the dependencies project-info report is included. My environment is:
Maven version: 2.0.9
Java version: 1.5.0_14
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
The attachment "MPIR-144-example2.zip" illustrates the problem and has maven output illustrating the problem, including versions with --debug turned on.
This is a multi-module project. Project A creates both main and test jars. Project B uses Project A main in its main branch, and both Project A main and test jars in its test branch. Project C uses Project A's main jar in both its main and test branches, but does not use A's test jar at all.
"mvn clean install" in the root project directory succeeds, but "mvn clean install site" fails when trying to compile the test branch in Project C (after sucessfully completing Project A and Project B). It fails because when it compiles C's tests, only A's test jar is on the classpath, and not A's main jar (you can see this in the file "clean-install-site-output-debug.txt" in the attached zip file, and compare to the correct behavior shown in "clean-install-output-debug.txt"). Project C's pom, however, only lists a dependency on A's main jar, not on its test jar.
If you comment out the "dependencies" report line in the root pom under maven-project-info-reports-plugin, then "mvn clean install site" works. It also works if you include the dependencies report but use version 2.0.1 of maven-project-info-reports-plugin. Finally, if you change Project B so that its tests don't require Project A's test jar, and remove the test-jar dependency from Project B's pom, it works. In other words, the problem only happens when both the dependencies report is included, and when a project that is processed before Project C has a dependency on Project A's test jar.
> 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
[jira] Commented: (MPIR-144) Dependency report introduces
corruption in classpaths for other plugins
Posted by "Vincent Siveton (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MPIR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=167246#action_167246 ]
Vincent Siveton commented on MPIR-144:
--------------------------------------
could be related to MPIR-146
> 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
[jira] Issue Comment Edited: (MPIR-144) Dependency report
introduces corruption in classpaths for other plugins
Posted by "Gregg Yost (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MPIR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152492#action_152492 ]
gyost edited comment on MPIR-144 at 10/30/08 12:49 PM:
------------------------------------------------------------
Please note that Affects Versions for this currently says 2.1, but both me and the original reporter are experiencing this in earlier versions (2.0.8, 2.0.9), though the original reporter has also observed this in 2.1 (I haven't tested my problem in 2.1).
was (Author: gyost):
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
[jira] Commented: (MPIR-144) Dependency report introduces
corruption in classpaths for other plugins
Posted by "Dennis Lundberg (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MPIR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152615#action_152615 ]
Dennis Lundberg commented on MPIR-144:
--------------------------------------
The "Affects Version/s" field is for the Plugin's version - not Maven itself. 2.1 is the latest released version of Maven Project Info Reports Plugin.
> 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
[jira] Closed: (MPIR-144) Dependency report introduces corruption
in classpaths for other plugins
Posted by "Dennis Lundberg (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MPIR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Lundberg closed MPIR-144.
--------------------------------
Resolution: Duplicate
I can confirm that the example project fails with MPIR 2.1.
I can also confirm that the example project works with MPIR 2.1.1.
> 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
[jira] Commented: (MPIR-144) Dependency report introduces
corruption in classpaths for other plugins
Posted by "Carlos Sanchez (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MPIR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=262640#action_262640 ]
Carlos Sanchez commented on MPIR-144:
-------------------------------------
Opened a new issue per Neil's comments MPIR-223. Please check MPIR-146 too which this issue duplicates
> 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-2.3.1.zip, 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
[jira] Updated: (MPIR-144) Dependency report introduces corruption
in classpaths for other plugins
Posted by "Neil Hartner (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MPIR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Neil Hartner updated MPIR-144:
------------------------------
Attachment: maven-project-info-report-defect-2.3.1.zip
> 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-2.3.1.zip, 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
[jira] Commented: (MPIR-144) Dependency report introduces
corruption in classpaths for other plugins
Posted by "Neil Hartner (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MPIR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=262600#action_262600 ]
Neil Hartner commented on MPIR-144:
-----------------------------------
This issue has reappeared in 2.3.1. I don't seem to have permissions to reopen this issue. I'm attaching an updated version of the zipped maven project that reproduces this issue. You can change which version of MPIR plugin to use with -Dmpir-version. For example:
mvn clean install site:site -Dmpir-version=2.3.1
2.1, 2.3 and 2.3.1 will fail
2.1.1 and 2.2 will succeed
> 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
[jira] Commented: (MPIR-144) Dependency report introduces
corruption in classpaths for other plugins
Posted by "Carlos Sanchez (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MPIR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=154685#action_154685 ]
Carlos Sanchez commented on MPIR-144:
-------------------------------------
experienced here too, with my own project
> 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