[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
