[jira] (MJAVADOC-408) changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
[ https://jira.codehaus.org/browse/MJAVADOC-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353099#comment-353099 ] Jeffrey Hagelberg commented on MJAVADOC-408: we're seeing this as well in our builds. changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build - Key: MJAVADOC-408 URL: https://jira.codehaus.org/browse/MJAVADOC-408 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.10 Environment: Linux, Windows 7, Oracle Java 1.6.0_45, maven 3.0.5 Reporter: Volker Seibt Priority: Critical Attachments: console.log, pom.xml, pom.xml build is startet with {{mvn -U clean deploy -DperformRelease=true}} and worked fine for several weeks without any changes. From today it produces the content of the attached console.log. We did not specify a version for maven-javadoc-plugin. After secifying maven-javadoc-plugin:2.9.1 in the parent pom everything works fine again. (pom.xml (12 kB) - parent-pom, pom.xml (3 kB) pom of project which breaks the build -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-408) changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build
[ https://jira.codehaus.org/browse/MJAVADOC-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353100#comment-353100 ] Jeffrey Hagelberg commented on MJAVADOC-408: FYI - if you have a multi-module build, you can work around it by adding 2.9.1 to the pluginManagement section in the root pom.xml, eg pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.9.1/version /plugin /plugins /pluginManagement changing maven-javadoc-plugin from version 2.9.1 to 2.10 breaks the build - Key: MJAVADOC-408 URL: https://jira.codehaus.org/browse/MJAVADOC-408 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.10 Environment: Linux, Windows 7, Oracle Java 1.6.0_45, maven 3.0.5 Reporter: Volker Seibt Priority: Critical Attachments: console.log, pom.xml, pom.xml build is startet with {{mvn -U clean deploy -DperformRelease=true}} and worked fine for several weeks without any changes. From today it produces the content of the attached console.log. We did not specify a version for maven-javadoc-plugin. After secifying maven-javadoc-plugin:2.9.1 in the parent pom everything works fine again. (pom.xml (12 kB) - parent-pom, pom.xml (3 kB) pom of project which breaks the build -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-225) javac.bat and args file added to archive when fork and -X used
Jeffrey Hagelberg created MCOMPILER-225: --- Summary: javac.bat and args file added to archive when fork and -X used Key: MCOMPILER-225 URL: https://jira.codehaus.org/browse/MCOMPILER-225 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 3.1, 2.3.2 Environment: Windows 7 x64 Reporter: Jeffrey Hagelberg When you compile a java project with -X flag and forktrue/fork in the maven-compiler-plugin configuration, the following extra files are written to target\classes and bundled in the root directory of the jar: javac.bat org.codehaus.plexus.compiler.javac.JavacCompiler8515975925044691799arguments The precise name of the arguments file varies from build to build. The exact configuration we are using is: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.6/source target1.6/target forktrue/fork showDeprecationtrue/showDeprecation showWarningstrue/showWarnings /configuration /plugin We originally saw this in version 2.3.2 of the maven-compiler-plugin. I've verified that it also occurs in version 3.1. We are able to work around this issue by setting fork to false. This can be reproduced in any maven java project. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-225) javac.bat and args file added to archive when fork and -X used
[ https://jira.codehaus.org/browse/MCOMPILER-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeffrey Hagelberg updated MCOMPILER-225: Description: When you compile a java project with -X flag and forktrue/fork in the maven-compiler-plugin configuration, the following extra files are written to target\classes and bundled in the root directory of the jar: javac.bat org.codehaus.plexus.compiler.javac.JavacCompiler8515975925044691799arguments The precise name of the arguments file varies from build to build. The exact configuration we are using is: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.6/source target1.6/target forktrue/fork showDeprecationtrue/showDeprecation showWarningstrue/showWarnings /configuration /plugin We originally saw this in version 2.3.2 of the maven-compiler-plugin. I've verified that it also occurs in version 3.1. We are able to work around this issue by setting fork to false. This can be reproduced in any maven java project. The issue also only occurs when the -X maven option is used to enable debug output. was: When you compile a java project with -X flag and forktrue/fork in the maven-compiler-plugin configuration, the following extra files are written to target\classes and bundled in the root directory of the jar: javac.bat org.codehaus.plexus.compiler.javac.JavacCompiler8515975925044691799arguments The precise name of the arguments file varies from build to build. The exact configuration we are using is: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.6/source target1.6/target forktrue/fork showDeprecationtrue/showDeprecation showWarningstrue/showWarnings /configuration /plugin We originally saw this in version 2.3.2 of the maven-compiler-plugin. I've verified that it also occurs in version 3.1. We are able to work around this issue by setting fork to false. This can be reproduced in any maven java project. javac.bat and args file added to archive when fork and -X used -- Key: MCOMPILER-225 URL: https://jira.codehaus.org/browse/MCOMPILER-225 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 2.3.2, 3.1 Environment: Windows 7 x64 Reporter: Jeffrey Hagelberg When you compile a java project with -X flag and forktrue/fork in the maven-compiler-plugin configuration, the following extra files are written to target\classes and bundled in the root directory of the jar: javac.bat org.codehaus.plexus.compiler.javac.JavacCompiler8515975925044691799arguments The precise name of the arguments file varies from build to build. The exact configuration we are using is: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.6/source target1.6/target forktrue/fork showDeprecationtrue/showDeprecation showWarningstrue/showWarnings /configuration /plugin We originally saw this in version 2.3.2 of the maven-compiler-plugin. I've verified that it also occurs in version 3.1. We are able to work around this issue by setting fork to false. This can be reproduced in any maven java project. The issue also only occurs when the -X maven option is used to enable debug output. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-225) javac.bat and args file added to archive when fork and -X used
[ https://jira.codehaus.org/browse/MCOMPILER-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeffrey Hagelberg updated MCOMPILER-225: Description: When you compile a java project with -X maven option and forktrue/fork in the maven-compiler-plugin configuration, the following extra files are written to target\classes and bundled in the root directory of the jar: javac.bat org.codehaus.plexus.compiler.javac.JavacCompiler8515975925044691799arguments The precise name of the arguments file varies from build to build. The exact configuration we are using is: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.6/source target1.6/target forktrue/fork showDeprecationtrue/showDeprecation showWarningstrue/showWarnings /configuration /plugin We originally saw this in version 2.3.2 of the maven-compiler-plugin. I've verified that it also occurs in version 3.1. We are able to work around this issue by setting fork to false. The issue also does not occur if -X is not used. This can be reproduced in any maven java project. was: When you compile a java project with -X flag and forktrue/fork in the maven-compiler-plugin configuration, the following extra files are written to target\classes and bundled in the root directory of the jar: javac.bat org.codehaus.plexus.compiler.javac.JavacCompiler8515975925044691799arguments The precise name of the arguments file varies from build to build. The exact configuration we are using is: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.6/source target1.6/target forktrue/fork showDeprecationtrue/showDeprecation showWarningstrue/showWarnings /configuration /plugin We originally saw this in version 2.3.2 of the maven-compiler-plugin. I've verified that it also occurs in version 3.1. We are able to work around this issue by setting fork to false. This can be reproduced in any maven java project. The issue also only occurs when the -X maven option is used to enable debug output. javac.bat and args file added to archive when fork and -X used -- Key: MCOMPILER-225 URL: https://jira.codehaus.org/browse/MCOMPILER-225 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 2.3.2, 3.1 Environment: Windows 7 x64 Reporter: Jeffrey Hagelberg When you compile a java project with -X maven option and forktrue/fork in the maven-compiler-plugin configuration, the following extra files are written to target\classes and bundled in the root directory of the jar: javac.bat org.codehaus.plexus.compiler.javac.JavacCompiler8515975925044691799arguments The precise name of the arguments file varies from build to build. The exact configuration we are using is: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.6/source target1.6/target forktrue/fork showDeprecationtrue/showDeprecation showWarningstrue/showWarnings /configuration /plugin We originally saw this in version 2.3.2 of the maven-compiler-plugin. I've verified that it also occurs in version 3.1. We are able to work around this issue by setting fork to false. The issue also does not occur if -X is not used. This can be reproduced in any maven java project. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5426) plugin configuration using alias is ignored for array types
Jeffrey Hagelberg created MNG-5426: -- Summary: plugin configuration using alias is ignored for array types Key: MNG-5426 URL: https://jira.codehaus.org/browse/MNG-5426 Project: Maven 2 3 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 2.0.10 Environment: Windows XP Reporter: Jeffrey Hagelberg In our pom.xml, we are configuration a plugin using the alias rather than the plugin parameter name. The configuration we are using is something like: configuration models model groupIdcom.ibm.mmi.models/groupId artifactIdmmi_compiled_archive/artifactId version${project.version}/version /model /models /configuration This is configuring the following plugin parameter in our Mojo: /** * * @parameter alias=models * @required */ private Model[] models_; When we run our build it fails with: [INFO] One or more required plugin parameters are invalid/missing for 'xmeta-installer:deploy-models' [0] Inside the definition for plugin 'xmeta-installer-plugin' specify the following: configuration ... models_VALUE/models_ /configuration -OR- configuration ... modelsVALUE/models /configuration This happens despite the fact that the models configuration element is present. I spent some time in a debugger trying to figure out what was going on. I stepped through the logic in DefaultPluginManager.mergeMojoConfiguration and DefaultPluginManager.buildTopDownMergedConfiguration. What I see is that in fromPom maven is implicitly adding an models_/ tag to the configuration in the pom.xml and treating that as the dominant configuration. The logic is merging this tag with the real models/ tag in the plugin configuration, using that as the recessive value. The merge logic only looks at the child elements in the dominant configuration. In this case, there are none, so the merged configuration does not have the configuraition that was put into the pom.xml. Here is what I see in the debugger: pomConfig [ at DefaultPluginManager:1199 ] configuration models model groupIdcom.ibm.mmi.models/groupId artifactIdmmi_compiled_archive/artifactId version9.2-SNAPSHOT/version /model /models models_/ /configuration dominant parameter seen in buildTopDownMergedConfiguration: models_ /models_ recessive parameter seen in buildTopDownMergedConfiguration: models model groupIdcom.ibm.mmi.models/groupId artifactIdmmi_compiled_archive/artifactId version9.2-SNAPSHOT/version /model /models result of buildTopDownMergedConfiguration: models_ /models_ -- 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] (MNG-5231) absolute file path in distributionManagement.site.url in sub project is made relative to parent site.url
Jeffrey Hagelberg created MNG-5231: -- Summary: absolute file path in distributionManagement.site.url in sub project is made relative to parent site.url Key: MNG-5231 URL: https://jira.codehaus.org/browse/MNG-5231 Project: Maven 2 3 Issue Type: Bug Components: Inheritance and Interpolation, Sites Reporting Affects Versions: 3.0.3 Reporter: Jeffrey Hagelberg Attachments: Log.txt, testcase.zip I have attached a test case and a log file which illustrate this issue. Basically, the issue we are seeing is that we have two projects, base, and module where module inherits from base and is a module in base. In base, we have the site being deployed via scp to one location. In the module, we have attempted to override the site to make it deploy to a local file. We did this so we can test the site locally deploying it to the real location. In our scenario, the module project is owned by another group, and they will ultimately want to deploy their site someplace else. What happens is that when we run mvn site-deploy in the module project, instead of the site going to a file as we expect, maven actually attempts to upload it via scp. You can see from the log file that it is attempting to deploy the site for module via scp: [INFO] --- maven-site-plugin:3.0:deploy (default-deploy) @ module --- scpexe://www.example.com/1.0-SNAPSHOT/ - Session: Opened [INFO] Pushing D:\temp\siteInheritanceBroken\module\target\site [INFO] to scpexe://www.example.com/1.0-SNAPSHOT/file:///c:/temp/my-site This issue is hampering our ability to test the generation of our maven site. We have not tried deploying the module project to a different server yet. -- 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