[jira] (MNG-5245) upgrade default plugins versions
[ https://jira.codehaus.org/browse/MNG-5245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305439#comment-305439 ] Stanilslav Spiridonov commented on MNG-5245: Resolved in 2.12.1 > upgrade default plugins versions > > > Key: MNG-5245 > URL: https://jira.codehaus.org/browse/MNG-5245 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.0.4 >Reporter: Olivier Lamy > Fix For: 3.0.5 > > -- 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-5237) Cannot download maven dependencies through proxy
[ https://jira.codehaus.org/browse/MNG-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305435#comment-305435 ] Dominik Bartholdi commented on MNG-5237: will this get fixed with the next version? (when will that be?) > Cannot download maven dependencies through proxy > > > Key: MNG-5237 > URL: https://jira.codehaus.org/browse/MNG-5237 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 > Environment: windows xp64 using cygwin >Reporter: Niels Mordt-Ostergaard >Assignee: Jason van Zyl > > Using proxy in settings.xml, I was able to download maven dependencies in > 3.0.3, but this seems to be broken with 3.0.4: > Proxy definition in settings.xml (hidden ip adress below, but correct proxy > ip on my system): > > > optional > true > http > > > xxx.xx.xx.xx > 8080 > localhost|127.0.0.1 > > > Output from 3.0.3: > $ mvn -V clean > Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) > Maven home: C:\Program Files\apache-maven-3.0.3 > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: no_NO, platform encoding: Cp1252 > OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows" > [INFO] Scanning for projects... > [INFO] > [INFO] > > [INFO] Building > [INFO] > > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom > Downloaded: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom > (5 KB at 4.9 KB/sec) > . and so on... > Output from 3.0.4: > $ mvn -V clean > Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) > Maven home: C:\Program Files\apache-maven-3.0.4 > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: no_NO, platform encoding: Cp1252 > OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows" > [INFO] Scanning for projects... > [INFO] > [INFO] > > [INFO] Building > [INFO] > > Downloading: > http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 0.390s > [INFO] Finished at: Fri Feb 03 13:14:35 CET 2012 > [INFO] Final Memory: 5M/490M > [INFO] > > [ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.4.1 or one of > its dependencies could not be resolved: Failed to read artifact descriptor > for org.apache.maven.plugins:maven-clean-plugin:jar:2.4.1: Could not transfer > artifact org.apache.maven.plugins:maven-clean-plugin:pom:2.4.1 from/to > central (http://repo.maven.apache.org/maven2): Access denied to: > http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom, > ReasonPhrase:Forbidden. -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException -- 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] (MINDEXER-54) setting user agent should be more straightforward
Milos Kleint created MINDEXER-54: Summary: setting user agent should be more straightforward Key: MINDEXER-54 URL: https://jira.codehaus.org/browse/MINDEXER-54 Project: Maven Indexer Issue Type: Bug Affects Versions: 4.1.2 Reporter: Milos Kleint setting user agent should be more straightforward especially since central started rejecting requests without a user agent. please see https://hg.netbeans.org/core-main/rev/1aa01e27dd62 and http://netbeans.org/bugzilla/show_bug.cgi?id=215343 for details -- 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] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305403#comment-305403 ] Alex Halovanic commented on MEAR-146: - I'll rework patch to be in a WebLogic section then. > Expose parameter to not write library-directory element in application.xml > -- > > Key: MEAR-146 > URL: https://jira.codehaus.org/browse/MEAR-146 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.7 > Environment: Oracle WebLogic >Reporter: Alex Halovanic >Priority: Minor > Attachments: ear-remove-librarydirectory-IT.patch, > ear-remove-librarydirectory.patch > > > The current handling of defaultLibBundleDir leads to some issues on Oracle > Weblogic 10+. The Ear plugin currently sets library-directory to the value > of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's > classloading features break (specifically "Generic File Loading") when this > element is set. defaultLibBundleDir has to be set to APP-INF/lib since this > is the magic library folder for WebLogic. > The patch adds a parameter to prevent setting library-directory for cases > like this. -- 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] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305400#comment-305400 ] Sean Gurevich edited comment on MEAR-146 at 8/2/12 5:32 PM: That would work and be clear. BTW, I mentioned this side-effect to an Architect at Oracle during a sales meeting. She said that she would pass along the issue to the team. I have not heard back from anyone or have seen a new version of WebLogic, yet. Thanks for providing a workaround! was (Author: seanpublic): That would work and be clear. BTW, I mentioned this side-effect to an Architect at Oracle during a sales meeting. She said that she would pass along the issue to the team. I have not heard back or seen a new version of WebLogic, yet. Thanks for providing a workaround! > Expose parameter to not write library-directory element in application.xml > -- > > Key: MEAR-146 > URL: https://jira.codehaus.org/browse/MEAR-146 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.7 > Environment: Oracle WebLogic >Reporter: Alex Halovanic >Priority: Minor > Attachments: ear-remove-librarydirectory-IT.patch, > ear-remove-librarydirectory.patch > > > The current handling of defaultLibBundleDir leads to some issues on Oracle > Weblogic 10+. The Ear plugin currently sets library-directory to the value > of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's > classloading features break (specifically "Generic File Loading") when this > element is set. defaultLibBundleDir has to be set to APP-INF/lib since this > is the magic library folder for WebLogic. > The patch adds a parameter to prevent setting library-directory for cases > like this. -- 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] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305400#comment-305400 ] Sean Gurevich commented on MEAR-146: That would work and be clear. BTW, I mentioned this side-effect to an Architect at Oracle during a sales meeting. She said that she would pass along the issue to the team. I have not heard back or seen a new version of WebLogic, yet. Thanks for providing a workaround! > Expose parameter to not write library-directory element in application.xml > -- > > Key: MEAR-146 > URL: https://jira.codehaus.org/browse/MEAR-146 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.7 > Environment: Oracle WebLogic >Reporter: Alex Halovanic >Priority: Minor > Attachments: ear-remove-librarydirectory-IT.patch, > ear-remove-librarydirectory.patch > > > The current handling of defaultLibBundleDir leads to some issues on Oracle > Weblogic 10+. The Ear plugin currently sets library-directory to the value > of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's > classloading features break (specifically "Generic File Loading") when this > element is set. defaultLibBundleDir has to be set to APP-INF/lib since this > is the magic library folder for WebLogic. > The patch adds a parameter to prevent setting library-directory for cases > like this. -- 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] (ARCHETYPE-418) use plugin annotations
[ https://jira.codehaus.org/browse/ARCHETYPE-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed ARCHETYPE-418. -- Resolution: Fixed > use plugin annotations > -- > > Key: ARCHETYPE-418 > URL: https://jira.codehaus.org/browse/ARCHETYPE-418 > Project: Maven Archetype > Issue Type: Bug > Components: Plugin >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.3 > > -- 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] (MASSEMBLY-620) The dependencySet/includes/include format is documented incorrectly
Laird Nelson created MASSEMBLY-620:
--
Summary: The dependencySet/includes/include format is documented
incorrectly
Key: MASSEMBLY-620
URL: https://jira.codehaus.org/browse/MASSEMBLY-620
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.3
Reporter: Laird Nelson
The proper format for {{}} elements should be:
{code}
groupId:artifactId:type:classifier[:version]
{code}
The
[documentation|http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_dependencySet]
given by the {{maven-assembly-plugin}} says (incorrectly):
{quote}
Artifact coordinatess may be given in simple groupId:artifactId form, or they
may be fully qualified in the form groupId:artifactId:type:version[:classifier].
{quote}
Additionally, the Sonatype book
[says|http://www.sonatype.com/books/mvnref-book/reference/assemblies-sect-controlling-contents.html#assemblies-sect-fine-tune]
(incorrectly? or maybe just confusingly):
{quote}
groupId:artifactId:type[:classifier]:version - full artifact identity
If you need to get really specific, you can specify all the coordinates.
{quote}
--
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] (ARCHETYPE-418) use plugin annotations
Olivier Lamy created ARCHETYPE-418: -- Summary: use plugin annotations Key: ARCHETYPE-418 URL: https://jira.codehaus.org/browse/ARCHETYPE-418 Project: Maven Archetype Issue Type: Bug Components: Plugin Reporter: Olivier Lamy -- 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] (ARCHETYPE-418) use plugin annotations
[ https://jira.codehaus.org/browse/ARCHETYPE-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated ARCHETYPE-418: --- Fix Version/s: 2.3 Assignee: Olivier Lamy > use plugin annotations > -- > > Key: ARCHETYPE-418 > URL: https://jira.codehaus.org/browse/ARCHETYPE-418 > Project: Maven Archetype > Issue Type: Bug > Components: Plugin >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.3 > > -- 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] (MARCHETYPES-40) Use new annotations with Plugin Archetype
[ https://jira.codehaus.org/browse/MARCHETYPES-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MARCHETYPES-40: Fix Version/s: maven-archetype-plugin-1.2 > Use new annotations with Plugin Archetype > -- > > Key: MARCHETYPES-40 > URL: https://jira.codehaus.org/browse/MARCHETYPES-40 > Project: Maven Archetype Bundles > Issue Type: Bug > Components: Maven Plugin Archetype >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: maven-archetype-plugin-1.2 > > -- 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] (MARCHETYPES-40) Use new annotations with Plugin Archetype
[ https://jira.codehaus.org/browse/MARCHETYPES-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MARCHETYPES-40. --- Resolution: Fixed Assignee: Olivier Lamy fixed r1368704 > Use new annotations with Plugin Archetype > -- > > Key: MARCHETYPES-40 > URL: https://jira.codehaus.org/browse/MARCHETYPES-40 > Project: Maven Archetype Bundles > Issue Type: Bug > Components: Maven Plugin Archetype >Reporter: Olivier Lamy >Assignee: Olivier Lamy > -- 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] (MCHANGELOG-79) Add support for "tag" type report of Subversion
[
https://jira.codehaus.org/browse/MCHANGELOG-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305384#comment-305384
]
Samuel Van Reeth edited comment on MCHANGELOG-79 at 8/2/12 4:03 PM:
I created a new patch for this problem.
It is a new implementation, using the forked SvnInfoCommandExpanded class from
Jerome Lacoste but without the SvnTrunkChangeLogCommand class and without the
need for the branchBase property.
@Dave: check issue MCHANGELOG-108 - read/write changelog.xml inconsistency
was (Author: rodikal):
I created a new patch for this problem.
It is a new implementation, using the forked SvnInfoCommandExpanded class from
Jerome Lacoste but without the SvnTrunkChangeLogCommand class and without the
need for the branchBase property.
> Add support for "tag" type report of Subversion
> ---
>
> Key: MCHANGELOG-79
> URL: https://jira.codehaus.org/browse/MCHANGELOG-79
> Project: Maven 2.x Changelog Plugin
> Issue Type: Improvement
>Reporter: Kinugasa Noriko
> Attachments:
> MCHANGELOG-79_0001-Add-support-for-svn-tag-diffs.-Redo-the-original-MCH.patch,
>
> MCHANGELOG-79-Add-support-for-svn-tag-diffs-New-Patch-no-BranchBase-property.patch,
> SvnTag_changelog.patch, svntag-report-sample.JPG
>
>
> Currently, Changelog plugin don't support Subversion's tag.
> This patch make The "tag" type report available even if you are using
> Subversion.
> This gets each revision of tags in Subversion system, and generates the
> log-report between those revisions.
> For example, assume you have following repositoy structure:
> {noformat}
> http://example.com/svn/project
> +trunk/
> |+src/
> | ...
> +tags/
> |+1.0/
> |+1.1/
> |+1.2/
> |+2.0/
> |+2.1/
> +branches/
> +1.x/
> {noformat}
> To generate svn log's between 1.1 and 1.2 tag in 1.x branch:
> [pom.xml]
> {code:xml}
> ...
>
>
>
> scm:svn:http://example.com/svn/project
>
> ...
>
>
>
>
> org.apache.maven.plugins
> maven-changelog-plugin
> 2.2.1
>
>
> tag
>
>
> 1.2
> 1.1
>
>
> branches/1.x
>
> Windows-31J
>
>
>
>
> ...
> {code}
> To generate svn log-report between 2.1 and 2.0 tag in trunk:
> [pom.xml]
> {code:xml}
> ...
>
>
>
> scm:svn:http://example.com/svn/project
>
> ...
>
>
>
>
> org.apache.maven.plugins
> maven-changelog-plugin
> 2.2.1
>
>
> tag
>
>
> 2.0
> 2.1
>
>
> [trunk]
>
> Windows-31J
>
>
>
>
> ...
> {code}
--
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] (MCHANGELOG-79) Add support for "tag" type report of Subversion
[
https://jira.codehaus.org/browse/MCHANGELOG-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samuel Van Reeth updated MCHANGELOG-79:
---
Attachment:
MCHANGELOG-79-Add-support-for-svn-tag-diffs-New-Patch-no-BranchBase-property.patch
I created a new patch for this problem.
It is a new implementation, using the forked SvnInfoCommandExpanded class from
Jerome Lacoste but without the SvnTrunkChangeLogCommand class and without the
need for the branchBase property.
> Add support for "tag" type report of Subversion
> ---
>
> Key: MCHANGELOG-79
> URL: https://jira.codehaus.org/browse/MCHANGELOG-79
> Project: Maven 2.x Changelog Plugin
> Issue Type: Improvement
>Reporter: Kinugasa Noriko
> Attachments:
> MCHANGELOG-79_0001-Add-support-for-svn-tag-diffs.-Redo-the-original-MCH.patch,
>
> MCHANGELOG-79-Add-support-for-svn-tag-diffs-New-Patch-no-BranchBase-property.patch,
> SvnTag_changelog.patch, svntag-report-sample.JPG
>
>
> Currently, Changelog plugin don't support Subversion's tag.
> This patch make The "tag" type report available even if you are using
> Subversion.
> This gets each revision of tags in Subversion system, and generates the
> log-report between those revisions.
> For example, assume you have following repositoy structure:
> {noformat}
> http://example.com/svn/project
> +trunk/
> |+src/
> | ...
> +tags/
> |+1.0/
> |+1.1/
> |+1.2/
> |+2.0/
> |+2.1/
> +branches/
> +1.x/
> {noformat}
> To generate svn log's between 1.1 and 1.2 tag in 1.x branch:
> [pom.xml]
> {code:xml}
> ...
>
>
>
> scm:svn:http://example.com/svn/project
>
> ...
>
>
>
>
> org.apache.maven.plugins
> maven-changelog-plugin
> 2.2.1
>
>
> tag
>
>
> 1.2
> 1.1
>
>
> branches/1.x
>
> Windows-31J
>
>
>
>
> ...
> {code}
> To generate svn log-report between 2.1 and 2.0 tag in trunk:
> [pom.xml]
> {code:xml}
> ...
>
>
>
> scm:svn:http://example.com/svn/project
>
> ...
>
>
>
>
> org.apache.maven.plugins
> maven-changelog-plugin
> 2.2.1
>
>
> tag
>
>
> 2.0
> 2.1
>
>
> [trunk]
>
> Windows-31J
>
>
>
>
> ...
> {code}
--
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] (MDEP-259) copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"
[
https://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305383#comment-305383
]
Ian Brandt commented on MDEP-259:
-
@Andreas: No worries. I'm going to work on some tests to better understand how
the resolver behaves in various reactor scenarios. I'll see if I can't
rediscover the issue you encountered.
> copy-dependencies fails with "Error copying artifact from .../target/classes
> to .../classes"
>
>
> Key: MDEP-259
> URL: https://jira.codehaus.org/browse/MDEP-259
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: copy, copy-dependencies
>Affects Versions: 2.0, 2.1
> Environment: Maven 2.0.9
> maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616)
>Reporter: Andreas Veithen
> Attachments: patch.txt, test-project.zip
>
>
> Scenario:
> * dependency:copy-dependencies is used to copy a dependency artifact that is
> part of the same multi-module build.
> * The compile phase is executed, but not the package phase.
> An example of this scenario is using maven-eclipse-plugin to import a Maven
> project with generated test (re)sources. In this case, one would execute "mvn
> generate-test-resources eclipse:eclipse" to make sure that the generated
> (re)sources are imported into the workspace (by default, maven-eclipse-plugin
> executes generate-sources and generate-resources, but not
> generate-test-sources and generate-test-resources).
> Result: The build fails with the following error:
> {noformat}[INFO] [dependency:copy-dependencies {execution: default}]
> [INFO] Copying classes to
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error copying artifact from
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> Embedded error:
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No
> such file or directory){noformat}
> Steps to reproduce:
> * Unpack the attached test project and build the entire project once with
> "mvn install".
> * Execute "mvn generate-resources" from the root project -> success (because
> the compile phase is not executed)
> * Execute "mvn package" from the root project -> success (because the package
> phase is executed)
> * Execute "mvn generate-test-resources" from the root project -> fails
> (because the compile phase is executed, but not the package phase)
> * Execute "mvn generate-test-resources" in project2 -> success (because the
> dependency is not part of the same build)
> Root cause analysis: In the scenario described above (compile phase executed,
> package phase not executed), Artifact#getFile() points to the target/classes
> directory instead of the output artifact. dependency:copy-dependencies
> doesn't detect this situation and blindly attempts to execute the copy
> operation. This fails with the error message shown above. Note that even if
> the operation didn't fail, it would produce an unexpected result.
> Proposed fix (see attached patch): Change maven-dependency-plugin to detect
> this situation and let it replace the original Artifact object by a new one
> resolved from the repository (which would then refer to the artifact
> generated by a previous build, exactly as in the mvn generate-resources case).
--
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] (MDEP-259) copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"
[
https://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305380#comment-305380
]
Andreas Veithen commented on MDEP-259:
--
@Ian: Sorry, I did that several months ago and I don't remember the details.
> copy-dependencies fails with "Error copying artifact from .../target/classes
> to .../classes"
>
>
> Key: MDEP-259
> URL: https://jira.codehaus.org/browse/MDEP-259
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: copy, copy-dependencies
>Affects Versions: 2.0, 2.1
> Environment: Maven 2.0.9
> maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616)
>Reporter: Andreas Veithen
> Attachments: patch.txt, test-project.zip
>
>
> Scenario:
> * dependency:copy-dependencies is used to copy a dependency artifact that is
> part of the same multi-module build.
> * The compile phase is executed, but not the package phase.
> An example of this scenario is using maven-eclipse-plugin to import a Maven
> project with generated test (re)sources. In this case, one would execute "mvn
> generate-test-resources eclipse:eclipse" to make sure that the generated
> (re)sources are imported into the workspace (by default, maven-eclipse-plugin
> executes generate-sources and generate-resources, but not
> generate-test-sources and generate-test-resources).
> Result: The build fails with the following error:
> {noformat}[INFO] [dependency:copy-dependencies {execution: default}]
> [INFO] Copying classes to
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error copying artifact from
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> Embedded error:
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No
> such file or directory){noformat}
> Steps to reproduce:
> * Unpack the attached test project and build the entire project once with
> "mvn install".
> * Execute "mvn generate-resources" from the root project -> success (because
> the compile phase is not executed)
> * Execute "mvn package" from the root project -> success (because the package
> phase is executed)
> * Execute "mvn generate-test-resources" from the root project -> fails
> (because the compile phase is executed, but not the package phase)
> * Execute "mvn generate-test-resources" in project2 -> success (because the
> dependency is not part of the same build)
> Root cause analysis: In the scenario described above (compile phase executed,
> package phase not executed), Artifact#getFile() points to the target/classes
> directory instead of the output artifact. dependency:copy-dependencies
> doesn't detect this situation and blindly attempts to execute the copy
> operation. This fails with the error message shown above. Note that even if
> the operation didn't fail, it would produce an unexpected result.
> Proposed fix (see attached patch): Change maven-dependency-plugin to detect
> this situation and let it replace the original Artifact object by a new one
> resolved from the repository (which would then refer to the artifact
> generated by a previous build, exactly as in the mvn generate-resources case).
--
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] (MRAR-22) Allow filtering of source resources
[ https://jira.codehaus.org/browse/MRAR-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRAR-22. Resolution: Fixed > Allow filtering of source resources > > > Key: MRAR-22 > URL: https://jira.codehaus.org/browse/MRAR-22 > Project: Maven 2.x Rar Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Basil James Whitehouse III >Assignee: Olivier Lamy > Fix For: 2.3 > > > There doesn't appear to be a way to filter the contents of /src/main/rar . > This would be very useful to filter the project version into Geronimo > specific descriptors (as well as other custom settings). -- 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] (MRAR-15) Allow more customizations of resources to be included
[
https://jira.codehaus.org/browse/MRAR-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MRAR-15.
Resolution: Fixed
> Allow more customizations of resources to be included
> -
>
> Key: MRAR-15
> URL: https://jira.codehaus.org/browse/MRAR-15
> Project: Maven 2.x Rar Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Jason Dillon
>Assignee: Olivier Lamy
> Fix For: 2.3
>
>
> Should allow more customizations of resources to include... similar to
> maven-war-plugin's {{}}.
--
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] (MRAR-15) Allow more customizations of resources to be included
[
https://jira.codehaus.org/browse/MRAR-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MRAR-15:
-
Fix Version/s: 2.3
Assignee: Olivier Lamy
> Allow more customizations of resources to be included
> -
>
> Key: MRAR-15
> URL: https://jira.codehaus.org/browse/MRAR-15
> Project: Maven 2.x Rar Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Jason Dillon
>Assignee: Olivier Lamy
> Fix For: 2.3
>
>
> Should allow more customizations of resources to include... similar to
> maven-war-plugin's {{}}.
--
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] (MRAR-15) Allow more customizations of resources to be included
[
https://jira.codehaus.org/browse/MRAR-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305374#comment-305374
]
Olivier Lamy commented on MRAR-15:
--
add a field rarResources which can contains resource to add/filter
> Allow more customizations of resources to be included
> -
>
> Key: MRAR-15
> URL: https://jira.codehaus.org/browse/MRAR-15
> Project: Maven 2.x Rar Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Jason Dillon
>Assignee: Olivier Lamy
> Fix For: 2.3
>
>
> Should allow more customizations of resources to include... similar to
> maven-war-plugin's {{}}.
--
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] (MRAR-22) Allow filtering of source resources
[ https://jira.codehaus.org/browse/MRAR-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MRAR-22: Assignee: Olivier Lamy > Allow filtering of source resources > > > Key: MRAR-22 > URL: https://jira.codehaus.org/browse/MRAR-22 > Project: Maven 2.x Rar Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Basil James Whitehouse III >Assignee: Olivier Lamy > Fix For: 2.3 > > > There doesn't appear to be a way to filter the contents of /src/main/rar . > This would be very useful to filter the project version into Geronimo > specific descriptors (as well as other custom settings). -- 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] (MRAR-22) Allow filtering of source resources
[ https://jira.codehaus.org/browse/MRAR-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305372#comment-305372 ] Olivier Lamy commented on MRAR-22: -- as it's a new feature will be off by default. > Allow filtering of source resources > > > Key: MRAR-22 > URL: https://jira.codehaus.org/browse/MRAR-22 > Project: Maven 2.x Rar Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Basil James Whitehouse III > Fix For: 2.3 > > > There doesn't appear to be a way to filter the contents of /src/main/rar . > This would be very useful to filter the project version into Geronimo > specific descriptors (as well as other custom settings). -- 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] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305369#comment-305369 ] Stéphane Nicoll commented on MEAR-146: -- So yes we can do that. A patch would obviously help integrating this feature (the one attached provides a general parameter, I don't think we should go that way. Starting weblogic specific options is probably the best option). > Expose parameter to not write library-directory element in application.xml > -- > > Key: MEAR-146 > URL: https://jira.codehaus.org/browse/MEAR-146 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.7 > Environment: Oracle WebLogic >Reporter: Alex Halovanic >Priority: Minor > Attachments: ear-remove-librarydirectory-IT.patch, > ear-remove-librarydirectory.patch > > > The current handling of defaultLibBundleDir leads to some issues on Oracle > Weblogic 10+. The Ear plugin currently sets library-directory to the value > of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's > classloading features break (specifically "Generic File Loading") when this > element is set. defaultLibBundleDir has to be set to APP-INF/lib since this > is the magic library folder for WebLogic. > The patch adds a parameter to prevent setting library-directory for cases > like this. -- 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] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stéphane Nicoll updated MEAR-146: - Affects Version/s: (was: 2.8) 2.7 > Expose parameter to not write library-directory element in application.xml > -- > > Key: MEAR-146 > URL: https://jira.codehaus.org/browse/MEAR-146 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.7 > Environment: Oracle WebLogic >Reporter: Alex Halovanic >Priority: Minor > Attachments: ear-remove-librarydirectory-IT.patch, > ear-remove-librarydirectory.patch > > > The current handling of defaultLibBundleDir leads to some issues on Oracle > Weblogic 10+. The Ear plugin currently sets library-directory to the value > of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's > classloading features break (specifically "Generic File Loading") when this > element is set. defaultLibBundleDir has to be set to APP-INF/lib since this > is the magic library folder for WebLogic. > The patch adds a parameter to prevent setting library-directory for cases > like this. -- 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] (MEAR-150) Support new 'no-version-for-ejb' file name mapping
[ https://jira.codehaus.org/browse/MEAR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stéphane Nicoll closed MEAR-150. Resolution: Fixed Applied, thanks. I used 'no-version-for-ejb' for the name to be consistent. Also deployed a 2.8-SNAPSHOT with the change. > Support new 'no-version-for-ejb' file name mapping > -- > > Key: MEAR-150 > URL: https://jira.codehaus.org/browse/MEAR-150 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.7 >Reporter: Philippe Marschall >Assignee: Stéphane Nicoll >Priority: Minor > Fix For: 2.8 > > Attachments: maven-ear-plugin.patch > > > JBoss 7 has a new [remote lookup naming > stragety|https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI?_sscc=t]. > The name of the ejb-jar is not part of remote name. If that includes the > version this is obviously going to cause problems. Using 'no-version' would > fix this but I would like to keep version of the library jars as a quick way > of verifying the ears contents. What this name mapping does is essentially > 'no-version' for ejb-jars, 'standard' for library jars. -- 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] (MEAR-150) Support new 'no-version-for-ejb' file name mapping
[ https://jira.codehaus.org/browse/MEAR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stéphane Nicoll updated MEAR-150: - Summary: Support new 'no-version-for-ejb' file name mapping (was: [patch] support new 'no-version-for-ejbs' file name mapping) > Support new 'no-version-for-ejb' file name mapping > -- > > Key: MEAR-150 > URL: https://jira.codehaus.org/browse/MEAR-150 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.7 >Reporter: Philippe Marschall >Assignee: Stéphane Nicoll >Priority: Minor > Fix For: 2.8 > > Attachments: maven-ear-plugin.patch > > > JBoss 7 has a new [remote lookup naming > stragety|https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI?_sscc=t]. > The name of the ejb-jar is not part of remote name. If that includes the > version this is obviously going to cause problems. Using 'no-version' would > fix this but I would like to keep version of the library jars as a quick way > of verifying the ears contents. What this name mapping does is essentially > 'no-version' for ejb-jars, 'standard' for library jars. -- 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] (MEAR-150) [patch] support new 'no-version-for-ejbs' file name mapping
[ https://jira.codehaus.org/browse/MEAR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stéphane Nicoll reassigned MEAR-150: Assignee: Stéphane Nicoll > [patch] support new 'no-version-for-ejbs' file name mapping > --- > > Key: MEAR-150 > URL: https://jira.codehaus.org/browse/MEAR-150 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.7 >Reporter: Philippe Marschall >Assignee: Stéphane Nicoll >Priority: Minor > Fix For: 2.8 > > Attachments: maven-ear-plugin.patch > > > JBoss 7 has a new [remote lookup naming > stragety|https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI?_sscc=t]. > The name of the ejb-jar is not part of remote name. If that includes the > version this is obviously going to cause problems. Using 'no-version' would > fix this but I would like to keep version of the library jars as a quick way > of verifying the ears contents. What this name mapping does is essentially > 'no-version' for ejb-jars, 'standard' for library jars. -- 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] (MRAR-9) Avoid to bundle rar dependencies (w/o scope=provided) inside the rar archive
[
https://jira.codehaus.org/browse/MRAR-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MRAR-9:
Fix Version/s: (was: 2.3)
2.4
> Avoid to bundle rar dependencies (w/o scope=provided) inside the rar archive
>
>
> Key: MRAR-9
> URL: https://jira.codehaus.org/browse/MRAR-9
> Project: Maven 2.x Rar Plugin
> Issue Type: New Feature
>Affects Versions: 2.1
> Environment: Maven 2.0.4
>Reporter: Carsten Karkola
>Assignee: Stéphane Nicoll
> Fix For: 2.4
>
>
> If I use "provided" the dependencies will never be included, my problem is
> 1. projects:
> my-jar
> rar1: dependency to my-jar
> rar2: dependency to my-jar
> ejb1: dependency to my-jar
> ear: dependency to rar1, rar2. ejb1
> 2. inside the ear:
> ejb1.jar
> rar1.rar
> rar2.rar
> lib/my-jar.jar
> 3. This works fine for packaging=ejb - the my-jar.jar gets copied to the lib
> dir during build of
> the ear. But the same jar gets also packaged in the rar1 and in the rar2
> archive. So I have it
> three times instead only having the entries in MANFIFEST.MF/Class-Path and
> the jar only
> once in the lib subdir.
> The Manifest entries are not the problem, to get the jar not packaged in the
> rars is my
> problem.
> 4. my proposal:
> add plugin configuration parameter
> false
> in RarMojo.java additional parameter and check:
> /**
> * Specify if the specified dependencies of this project should be
> * included in the rar file ; default is true.
> *
> * @parameter
> */
> private Boolean includeDependencies = Boolean.TRUE;
>
> // Copy dependencies
> try
> {
> if (includeDependencies.booleanValue()) { // additional check
> carsten
--
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] (MRAR-21) Non Java dependencies shouldn't be included in the RAR
[ https://jira.codehaus.org/browse/MRAR-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRAR-21. Resolution: Fixed patch applied Thanks > Non Java dependencies shouldn't be included in the RAR > -- > > Key: MRAR-21 > URL: https://jira.codehaus.org/browse/MRAR-21 > Project: Maven 2.x Rar Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Cédric Vidal >Assignee: Olivier Lamy > Fix For: 2.3 > > Attachments: MRAR-21-1.patch > > > Dependencies which are not added to classpath (more or less java > dependencies) should't be included in the RAR. -- 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] (MSOURCES-61) Reduce the logging level of the message indicated the resource has already been added to the archive
[
https://jira.codehaus.org/browse/MSOURCES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stéphane Nicoll updated MSOURCES-61:
Fix Version/s: (was: 2.1.2)
2.2
> Reduce the logging level of the message indicated the resource has already
> been added to the archive
>
>
> Key: MSOURCES-61
> URL: https://jira.codehaus.org/browse/MSOURCES-61
> Project: Maven 2.x Source Plugin
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Stéphane Nicoll
>Assignee: Stéphane Nicoll
> Fix For: 2.2
>
>
> The sources plugin output a lot of info message when a directory is present
> twice in his list.
> {noformat}
> [INFO] [source:jar-no-fork {execution: default-cli}]
> [INFO] org already added, skipping
> [INFO] org/sonar already added, skipping
> [INFO] org/sonar/plugins already added, skipping
> [INFO] org/sonar/plugins/findbugs already added, skipping
> {noformat}
> This log does not really add any extra value so it shoud be reduced to debug
--
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] (MRAR-21) Non Java dependencies shouldn't be included in the RAR
[ https://jira.codehaus.org/browse/MRAR-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MRAR-21: Assignee: Olivier Lamy > Non Java dependencies shouldn't be included in the RAR > -- > > Key: MRAR-21 > URL: https://jira.codehaus.org/browse/MRAR-21 > Project: Maven 2.x Rar Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Cédric Vidal >Assignee: Olivier Lamy > Fix For: 2.3 > > Attachments: MRAR-21-1.patch > > > Dependencies which are not added to classpath (more or less java > dependencies) should't be included in the RAR. -- 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] (SUREFIRE-896) surefire 2.12.1 doesn't work with maven 2.2.1
[
https://jira.codehaus.org/browse/SUREFIRE-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated SUREFIRE-896:
--
Priority: Blocker (was: Major)
> surefire 2.12.1 doesn't work with maven 2.2.1
> -
>
> Key: SUREFIRE-896
> URL: https://jira.codehaus.org/browse/SUREFIRE-896
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.12.1
>Reporter: Olivier Lamy
>Priority: Blocker
>
> log
> {code}
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] Unable to locate surefire-booter in the list of plugin artifacts
> [INFO]
>
> [INFO] Trace
> java.lang.RuntimeException: Unable to locate surefire-booter in the list of
> plugin artifacts
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.getForkConfiguration(AbstractSurefireMojo.java:1152)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:655)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAllProviders(AbstractSurefireMojo.java:647)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:606)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:569)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {code}
> env:
> {code}
> mbp-olamy:maven-plugin olamy$ mvn -v
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_33
> Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> Default locale: fr_FR, platform encoding: MacRoman
> OS name: "mac os x" version: "10.8" arch: "x86_64" Family: "mac"
> {code}
--
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] (SUREFIRE-896) surefire 2.12.1 doesn't work with maven 2.2.1
Olivier Lamy created SUREFIRE-896:
-
Summary: surefire 2.12.1 doesn't work with maven 2.2.1
Key: SUREFIRE-896
URL: https://jira.codehaus.org/browse/SUREFIRE-896
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.12.1
Reporter: Olivier Lamy
log
{code}
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Unable to locate surefire-booter in the list of plugin artifacts
[INFO]
[INFO] Trace
java.lang.RuntimeException: Unable to locate surefire-booter in the list of
plugin artifacts
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.getForkConfiguration(AbstractSurefireMojo.java:1152)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:655)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAllProviders(AbstractSurefireMojo.java:647)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:606)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:569)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
{code}
env:
{code}
mbp-olamy:maven-plugin olamy$ mvn -v
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_33
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: fr_FR, platform encoding: MacRoman
OS name: "mac os x" version: "10.8" arch: "x86_64" Family: "mac"
{code}
--
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] (MRELEASE-782) Properties defined in a child pom hide all the properties defined in the parent pom while performing release:prepare
[
https://jira.codehaus.org/browse/MRELEASE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305330#comment-305330
]
Robert Scholte commented on MRELEASE-782:
-
{quote}but why isn't it fixed?{quote}
* This issue is less then a month old and we're in the middle of the
holiday-season.
* There's a workaround.
* There are other issues with higher priority.
* No one has contributed a patch yet, including a test ( See [Stephen's
article|http://javaadventure.blogspot.nl/2012/07/do-you-want-to-become-maven-committer.html]
about contributing good patches )
Be aware that most developers have to do this in their own time.
By collecting votes and providing a patch you can increase the chance to get
this issue fixed.
> Properties defined in a child pom hide all the properties defined in the
> parent pom while performing release:prepare
>
>
> Key: MRELEASE-782
> URL: https://jira.codehaus.org/browse/MRELEASE-782
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.3.2
> Environment: Any
>Reporter: Marius Dumitru Florea
>
> Suppose you have this two poms:
> {code:title=Parent POM}
> ...
>
> 1.6
>
> ...
> {code}
> {code:title=Child POM}
> ...
>
> ...
>
> ...
>
>
> ...
> ${my.version}
>
>
>
> ...
> {code}
> Running release:prepare on this works just fine. Now, if we add a
> {{properties}} section with any property to the child pom we get:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
> project XYZ: The version could not be updated: ${my.version} -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare
> (default-cli) on project XYZ: The version could not be updated: ${my.version}
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoFailureException: The version could
> not be updated: ${commons.version}
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:299)
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:247)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.shared.release.ReleaseFailureException: The
> version could not be updated: ${my.version}
> at
> org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.rewriteArtifactVersions(AbstractRewritePomsPhase.java:578)
> at
> org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:298)
> at
> org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewri
[jira] (MRELEASE-511) release:prepare "Error parsing version, cannot determine next version: Unable to parse the version string" when running in batch mode.
[
https://jira.codehaus.org/browse/MRELEASE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305327#comment-305327
]
Robert Scholte commented on MRELEASE-511:
-
This part of the code needs some refactoring.
There are several issues related to this, so I'd prefer to do it good at once
instead of applying a lot of small patches for every new scenario.
A few weeks ago I finished the coverage tests, by now all known usecases should
be covered.
This issue is high on my todo-list, so hopefully it's fixed somewhere this
month.
> release:prepare "Error parsing version, cannot determine next version: Unable
> to parse the version string" when running in batch mode.
> --
>
> Key: MRELEASE-511
> URL: https://jira.codehaus.org/browse/MRELEASE-511
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9
> Environment: Win Xp Pro 64bit Java 1.6
>Reporter: David Cloutier
>Assignee: Robert Scholte
>Priority: Critical
> Attachments: patch_release_version_patterns.txt
>
>
> When I try to run release:prepare in batch mode, I get the error below (can't
> parse version string) even though I supply the version number by argument. If
> I do the same thing with the same versions in interactive mode, it works fine.
> Here is the output:
> {noformat}
> C:\workspaces\head\MyClient>mvn -B -e -Dresume=false -Dtag=PPX
> -DdevelopmentVersion=MYB_200909-SNAPSHOT -DreleaseVersion=PPX release:prepare
> release:perform
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed - com.mycie:MyClient:jar:MYB_200909-SNAPSHOT
> [INFO]task-segment: [release:prepare, release:perform] (aggregator-style)
> [INFO]
>
> Downloading:
> http://myrepo.int.mycie.com:8081/artifactory/repo/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases (http://myrepo.int.mycie.com:8081/artifactory/repo)
> Downloading:
> http://myrepo.int.mycie.com/artifactory/libs-releases-local/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases-local
> (http://myrepo.int.mycie.com/artifactory/libs-releases-local)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository central (http://repo1.maven.org/maven2)
> [INFO] [release:prepare {execution: default-cli}]
> [INFO] Verifying that there are no local modifications...
> [INFO] Executing: cmd.exe /X /C "cvs -z3 -f -t -d
> :pserver:usrbuild@mycvshost:/data/cvs/libcvs_web -n -q update -d"
> [INFO] Working directory: C:\workspaces\head\MyClient
> [INFO] Checking dependencies and plugins for snapshots ...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error parsing version, cannot determine next version: Unable to parse
> the version string: "MYB_200909-SNAPSHOT"
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing
> version, cannot determine next version: Unable to parse the version string:
> "MYB_200909-SNAPSHOT"
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
>
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[ https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305311#comment-305311 ] Ivan Bondarenko commented on MNG-2205: -- I have voted for this. Half-abstract and half-concrete example: A -> B(compile) -> servlet-api(provided), A must have an access to servlet-api classes (or at least have such possibility), because A must sit in web-container, so B has no other choice. In some cases A don't need classes from servlet-api, but this is not a problem, "compile" scope creates more problems in this case, because it pulls unnecessary dependencies along into package. I think the solution may be removing "optional" tag from dependency definition. Instead the tag "transitivity" can be introduced, which may be flexible and has different values: 1) 'transitive' - always transitive 2) 'optional' - as optional=true in current variant 3) 'detect' - transitive for cases when "The type cannot be resolved. It is indirectly referenced from required .class files" compile error appears 4) 'non-transitive' - always non-transitive 5) etc For backward compatibility 'transitive' can be default for "compile" scope and 'non-transitive' for "provided" > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: https://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 3.x / Backlog > > Attachments: transitivetest.zip > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect > So, does Project C transitively depend on Sybase JConnect. Yes, of course! > The "provided" dependency needs to be transitive. > Ultimately, when Project C gets deployed, Sybase JConnect needs to be > somewhere on the runtime classpath in order for the application to function. > It's valid for Project C to assume that Sybase JConnect is available and use > JDBC all over the Project C code. Project C is safe to do this because it can > happily deduce that Sybase JConnect will be there in the runtime environment > because Project A NEEDS IT. > I've got Use Cases all over my aggregated build which make it absolutely > critical and common sense that provided scope dependencies are transitive. > For the (very rare) odd case where you don't want to inherit provided > dependencies, you can them. -- 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] (MRELEASE-511) release:prepare "Error parsing version, cannot determine next version: Unable to parse the version string" when running in batch mode.
[
https://jira.codehaus.org/browse/MRELEASE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305309#comment-305309
]
Miguel Almeida commented on MRELEASE-511:
-
@Robert Scholte - any idea if this could be solved soon? Looks like it should
be easy to fix. Can you review the patch here? I can try to tackle this if you
need to.
> release:prepare "Error parsing version, cannot determine next version: Unable
> to parse the version string" when running in batch mode.
> --
>
> Key: MRELEASE-511
> URL: https://jira.codehaus.org/browse/MRELEASE-511
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9
> Environment: Win Xp Pro 64bit Java 1.6
>Reporter: David Cloutier
>Assignee: Robert Scholte
>Priority: Critical
> Attachments: patch_release_version_patterns.txt
>
>
> When I try to run release:prepare in batch mode, I get the error below (can't
> parse version string) even though I supply the version number by argument. If
> I do the same thing with the same versions in interactive mode, it works fine.
> Here is the output:
> {noformat}
> C:\workspaces\head\MyClient>mvn -B -e -Dresume=false -Dtag=PPX
> -DdevelopmentVersion=MYB_200909-SNAPSHOT -DreleaseVersion=PPX release:prepare
> release:perform
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed - com.mycie:MyClient:jar:MYB_200909-SNAPSHOT
> [INFO]task-segment: [release:prepare, release:perform] (aggregator-style)
> [INFO]
>
> Downloading:
> http://myrepo.int.mycie.com:8081/artifactory/repo/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases (http://myrepo.int.mycie.com:8081/artifactory/repo)
> Downloading:
> http://myrepo.int.mycie.com/artifactory/libs-releases-local/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository libs-releases-local
> (http://myrepo.int.mycie.com/artifactory/libs-releases-local)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/ws/security/wss4j/1.5.3/wss4j-1.5.3.pom
> [INFO] Unable to find resource 'org.apache.ws.security:wss4j:pom:1.5.3' in
> repository central (http://repo1.maven.org/maven2)
> [INFO] [release:prepare {execution: default-cli}]
> [INFO] Verifying that there are no local modifications...
> [INFO] Executing: cmd.exe /X /C "cvs -z3 -f -t -d
> :pserver:usrbuild@mycvshost:/data/cvs/libcvs_web -n -q update -d"
> [INFO] Working directory: C:\workspaces\head\MyClient
> [INFO] Checking dependencies and plugins for snapshots ...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error parsing version, cannot determine next version: Unable to parse
> the version string: "MYB_200909-SNAPSHOT"
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing
> version, cannot determine next version: Unable to parse the version string:
> "MYB_200909-SNAPSHOT"
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.Delegati
[jira] (MSOURCES-61) Reduce the logging level of the message indicated the resource has already been added to the archive
[
https://jira.codehaus.org/browse/MSOURCES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stéphane Nicoll closed MSOURCES-61.
---
Resolution: Fixed
> Reduce the logging level of the message indicated the resource has already
> been added to the archive
>
>
> Key: MSOURCES-61
> URL: https://jira.codehaus.org/browse/MSOURCES-61
> Project: Maven 2.x Source Plugin
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Stéphane Nicoll
>Assignee: Stéphane Nicoll
> Fix For: 2.1.2
>
>
> The sources plugin output a lot of info message when a directory is present
> twice in his list.
> {noformat}
> [INFO] [source:jar-no-fork {execution: default-cli}]
> [INFO] org already added, skipping
> [INFO] org/sonar already added, skipping
> [INFO] org/sonar/plugins already added, skipping
> [INFO] org/sonar/plugins/findbugs already added, skipping
> {noformat}
> This log does not really add any extra value so it shoud be reduced to debug
--
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] (MSOURCES-61) Reduce the logging level of the message indicated the resource has already been added to the archive
[
https://jira.codehaus.org/browse/MSOURCES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stéphane Nicoll updated MSOURCES-61:
Fix Version/s: 2.1.2
> Reduce the logging level of the message indicated the resource has already
> been added to the archive
>
>
> Key: MSOURCES-61
> URL: https://jira.codehaus.org/browse/MSOURCES-61
> Project: Maven 2.x Source Plugin
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Stéphane Nicoll
>Assignee: Stéphane Nicoll
> Fix For: 2.1.2
>
>
> The sources plugin output a lot of info message when a directory is present
> twice in his list.
> {noformat}
> [INFO] [source:jar-no-fork {execution: default-cli}]
> [INFO] org already added, skipping
> [INFO] org/sonar already added, skipping
> [INFO] org/sonar/plugins already added, skipping
> [INFO] org/sonar/plugins/findbugs already added, skipping
> {noformat}
> This log does not really add any extra value so it shoud be reduced to debug
--
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] (MSOURCES-61) Reduce the logging level of the message indicated the resource has already been added to the archive
[
https://jira.codehaus.org/browse/MSOURCES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stéphane Nicoll reassigned MSOURCES-61:
---
Assignee: Stéphane Nicoll
> Reduce the logging level of the message indicated the resource has already
> been added to the archive
>
>
> Key: MSOURCES-61
> URL: https://jira.codehaus.org/browse/MSOURCES-61
> Project: Maven 2.x Source Plugin
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Stéphane Nicoll
>Assignee: Stéphane Nicoll
> Fix For: 2.1.2
>
>
> The sources plugin output a lot of info message when a directory is present
> twice in his list.
> {noformat}
> [INFO] [source:jar-no-fork {execution: default-cli}]
> [INFO] org already added, skipping
> [INFO] org/sonar already added, skipping
> [INFO] org/sonar/plugins already added, skipping
> [INFO] org/sonar/plugins/findbugs already added, skipping
> {noformat}
> This log does not really add any extra value so it shoud be reduced to debug
--
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] (MSOURCES-61) Reduce the logging level of the message indicated the resource has already been added to the archive
[
https://jira.codehaus.org/browse/MSOURCES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305302#comment-305302
]
Stéphane Nicoll commented on MSOURCES-61:
-
actually this comes from plexus-archiver and this is fixed in 2.1.2
> Reduce the logging level of the message indicated the resource has already
> been added to the archive
>
>
> Key: MSOURCES-61
> URL: https://jira.codehaus.org/browse/MSOURCES-61
> Project: Maven 2.x Source Plugin
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Stéphane Nicoll
>Assignee: Stéphane Nicoll
> Fix For: 2.1.2
>
>
> The sources plugin output a lot of info message when a directory is present
> twice in his list.
> {noformat}
> [INFO] [source:jar-no-fork {execution: default-cli}]
> [INFO] org already added, skipping
> [INFO] org/sonar already added, skipping
> [INFO] org/sonar/plugins already added, skipping
> [INFO] org/sonar/plugins/findbugs already added, skipping
> {noformat}
> This log does not really add any extra value so it shoud be reduced to debug
--
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] (MSOURCES-61) Reduce the logging level of the message indicated the resource has already been added to the archive
Stéphane Nicoll created MSOURCES-61:
---
Summary: Reduce the logging level of the message indicated the
resource has already been added to the archive
Key: MSOURCES-61
URL: https://jira.codehaus.org/browse/MSOURCES-61
Project: Maven 2.x Source Plugin
Issue Type: Improvement
Affects Versions: 2.1.1
Reporter: Stéphane Nicoll
The sources plugin output a lot of info message when a directory is present
twice in his list.
{noformat}
[INFO] [source:jar-no-fork {execution: default-cli}]
[INFO] org already added, skipping
[INFO] org/sonar already added, skipping
[INFO] org/sonar/plugins already added, skipping
[INFO] org/sonar/plugins/findbugs already added, skipping
{noformat}
This log does not really add any extra value so it shoud be reduced to debug
--
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-5321) "IOException: Failed to delete repository.xml while trying to rename" during parallel build
[ https://jira.codehaus.org/browse/MNG-5321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-5321. - Resolution: Won't Fix Assignee: Brett Porter thanks > "IOException: Failed to delete repository.xml while trying to rename" during > parallel build > --- > > Key: MNG-5321 > URL: https://jira.codehaus.org/browse/MNG-5321 > Project: Maven 2 & 3 > Issue Type: Bug > Components: General >Affects Versions: 3.0.3 >Reporter: Victor Burdejny >Assignee: Brett Porter >Priority: Minor > Attachments: maven-repository-xml-issue.txt > > > The following problem has been found in console when parallel build was used > (-T command line parameter): > [INFO] --- maven-bundle-plugin:2.3.6:install (default-install) @ my-bundle --- > [WARNING] Exception while updating local OBR: IOException > org.apache.maven.plugin.MojoExecutionException: IOException > at > org.apache.felix.obrplugin.ObrUpdate.writeRepositoryXml(ObrUpdate.java:293) > at org.apache.felix.obrplugin.ObrInstall.execute(ObrInstall.java:149) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > ... > 'stderr' contains the following stacktrace: > java.io.IOException: Failed to delete c:\.m2\repository.xml while trying to > rename C:\Users\User\AppData\Local\Temp\repository8243840781003249024.xml > at org.codehaus.plexus.util.FileUtils.rename(FileUtils.java:2128) > at > org.apache.felix.obrplugin.ObrUpdate.writeRepositoryXml(ObrUpdate.java:288) > ... > Full stacktraces are provided in the attachment. > I did not find any problems that it causes for the build, but I suspect that > such problems might exist. The problem itself is (I suspect) a trivial race > condition. -- 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-5321) "IOException: Failed to delete repository.xml while trying to rename" during parallel build
[ https://jira.codehaus.org/browse/MNG-5321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305300#comment-305300 ] Victor Burdejny commented on MNG-5321: -- The problem has been reported to Felix community: https://issues.apache.org/jira/browse/FELIX-3619 > "IOException: Failed to delete repository.xml while trying to rename" during > parallel build > --- > > Key: MNG-5321 > URL: https://jira.codehaus.org/browse/MNG-5321 > Project: Maven 2 & 3 > Issue Type: Bug > Components: General >Affects Versions: 3.0.3 >Reporter: Victor Burdejny >Priority: Minor > Attachments: maven-repository-xml-issue.txt > > > The following problem has been found in console when parallel build was used > (-T command line parameter): > [INFO] --- maven-bundle-plugin:2.3.6:install (default-install) @ my-bundle --- > [WARNING] Exception while updating local OBR: IOException > org.apache.maven.plugin.MojoExecutionException: IOException > at > org.apache.felix.obrplugin.ObrUpdate.writeRepositoryXml(ObrUpdate.java:293) > at org.apache.felix.obrplugin.ObrInstall.execute(ObrInstall.java:149) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > ... > 'stderr' contains the following stacktrace: > java.io.IOException: Failed to delete c:\.m2\repository.xml while trying to > rename C:\Users\User\AppData\Local\Temp\repository8243840781003249024.xml > at org.codehaus.plexus.util.FileUtils.rename(FileUtils.java:2128) > at > org.apache.felix.obrplugin.ObrUpdate.writeRepositoryXml(ObrUpdate.java:288) > ... > Full stacktraces are provided in the attachment. > I did not find any problems that it causes for the build, but I suspect that > such problems might exist. The problem itself is (I suspect) a trivial race > condition. -- 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] (MRELEASE-782) Properties defined in a child pom hide all the properties defined in the parent pom while performing release:prepare
[
https://jira.codehaus.org/browse/MRELEASE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305297#comment-305297
]
Romain manni-Bucau commented on MRELEASE-782:
-
seems linked to line 538 in
http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
"Element property = properties.getChild( expression, properties.getNamespace()
);"
the else explicit this issue:
"
// the expression used to define the version of this artifact may be inherited
// TODO needs a better error message, what pom? what dependency?
throw new ReleaseFailureException( "The version could not be updated: " +
rawVersion );
"
but why isn't it fixed? At least an option to ignore the value and keep it
could be fine (typically a variable to define a version doesn't need any update)
> Properties defined in a child pom hide all the properties defined in the
> parent pom while performing release:prepare
>
>
> Key: MRELEASE-782
> URL: https://jira.codehaus.org/browse/MRELEASE-782
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.3.2
> Environment: Any
>Reporter: Marius Dumitru Florea
>
> Suppose you have this two poms:
> {code:title=Parent POM}
> ...
>
> 1.6
>
> ...
> {code}
> {code:title=Child POM}
> ...
>
> ...
>
> ...
>
>
> ...
> ${my.version}
>
>
>
> ...
> {code}
> Running release:prepare on this works just fine. Now, if we add a
> {{properties}} section with any property to the child pom we get:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
> project XYZ: The version could not be updated: ${my.version} -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare
> (default-cli) on project XYZ: The version could not be updated: ${my.version}
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoFailureException: The version could
> not be updated: ${commons.version}
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:299)
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:247)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.shared.release.ReleaseFailureException: The
> version could not be updated: ${my.version}
> at
> org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.rewriteArtifactVersions(AbstractRewritePomsPhase.java:578)
> at
> org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocum
[jira] (SUREFIRE-895) TestNG reporter options cannot be setup using the Maven Surefire Plugin
Bimal created SUREFIRE-895: -- Summary: TestNG reporter options cannot be setup using the Maven Surefire Plugin Key: SUREFIRE-895 URL: https://jira.codehaus.org/browse/SUREFIRE-895 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Reporter: Bimal TestNG reporter options cannot be setup using the Maven Surefire Plugin As per the TestNG (http://testng.org/doc/documentation-main.html#logging-reporters) Following options can be setup using Ant only outputDirectory timestampFormat fileFragmentationLevel splitClassAndPackageNames generateGroupsAttribute generateTestResultAttributes stackTraceOutputMethod generateDependsOnMethods generateDependsOnGroups In my project I'm using Maven. This cannot be achieved with Maven Surefire Plugin. Please Add this feature to Maven Surefire Plugin. -- 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-5321) "IOException: Failed to delete repository.xml while trying to rename" during parallel build
[ https://jira.codehaus.org/browse/MNG-5321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305290#comment-305290 ] Brett Porter commented on MNG-5321: --- This sounds like the maven-bundle-plugin is not thread-safe. That would need to be reported to the Felix community: https://issues.apache.org/jira/browse/FELIX/component/12311143 > "IOException: Failed to delete repository.xml while trying to rename" during > parallel build > --- > > Key: MNG-5321 > URL: https://jira.codehaus.org/browse/MNG-5321 > Project: Maven 2 & 3 > Issue Type: Bug > Components: General >Affects Versions: 3.0.3 >Reporter: Victor Burdejny >Priority: Minor > Attachments: maven-repository-xml-issue.txt > > > The following problem has been found in console when parallel build was used > (-T command line parameter): > [INFO] --- maven-bundle-plugin:2.3.6:install (default-install) @ my-bundle --- > [WARNING] Exception while updating local OBR: IOException > org.apache.maven.plugin.MojoExecutionException: IOException > at > org.apache.felix.obrplugin.ObrUpdate.writeRepositoryXml(ObrUpdate.java:293) > at org.apache.felix.obrplugin.ObrInstall.execute(ObrInstall.java:149) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > ... > 'stderr' contains the following stacktrace: > java.io.IOException: Failed to delete c:\.m2\repository.xml while trying to > rename C:\Users\User\AppData\Local\Temp\repository8243840781003249024.xml > at org.codehaus.plexus.util.FileUtils.rename(FileUtils.java:2128) > at > org.apache.felix.obrplugin.ObrUpdate.writeRepositoryXml(ObrUpdate.java:288) > ... > Full stacktraces are provided in the attachment. > I did not find any problems that it causes for the build, but I suspect that > such problems might exist. The problem itself is (I suspect) a trivial race > condition. -- 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] (MCHECKSTYLE-163) Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true
[
https://jira.codehaus.org/browse/MCHECKSTYLE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305287#comment-305287
]
Gerald Gloede commented on MCHECKSTYLE-163:
---
This issue doesn't seem to be completely fixed.
While the checkstyle:check goal is working as intended, the
checkstyle:checkstyle goal still reports that checkstyle is unable to get class
informations for exceptions which has been imported from a test-scope
dependency.
You can reproduce this behavior using the earlier provided example project.
I tried maven-checkstyle-plugin version 2.7 and 2.9.1 and maven version 2.2.1
and 3.0.4
> Test classpath resolution fails in mvn check:check when
> includeTestSourceDirectory = true
> -
>
> Key: MCHECKSTYLE-163
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-163
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Chris Whelan
>Assignee: Olivier Lamy
> Fix For: 2.7
>
> Attachments: MCHECKSTYLE-163.zip, resolveTestClasspath.patch
>
>
> When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the
> full test classpath should be made available to checkstyle. Patch included
> to resolve issue by setting @requiresDependencyResolution to test.
> In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured
> using the classpath string from
> request.getProject().getTestClasspathElements() (see
> DefaultCheckstyleExecutor line 114).
> However, the CheckstyleViolationCheckMojo only has
> @requiresDependencyResolution compile which means that pom dependencies which
> have been declared as test are not returned by
> project.getTestClasspathElements().
> This is a particular issue for the checkstyle RedundantThrows check
> (http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows) as it
> requires all Exceptions to be available on it's classpath.
> If code throws an Exception which has been imported from a maven
> test dependency, the exception will not be available on the
> classpath and this checkstyle check will fail.
> Example:
> Include junit as a test scope dependency in the project POM:
>
> junit
> junit
> ${junit.version}
> test
>
> Throw any junit exception within project test code, e.g.:
> public class MyCustomTestRunner extends BlockJUnit4ClassRunner {
> public MyCustomTestRunner(final Class klass) throws
> InitializationError {
> If RedundantThrows check is enabled, the following error will be thrown:
> [INFO] --- maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) @
> sample-project ---
> [INFO] Starting audit...
> C:\Working\hg\sample-project\src\test\java\com\sample\support\junit\MyCustomTestRunner.java:28:72:
> warning: Unable to get class information for InitializationError.
> Audit done.
> [ERROR] MyCustomTestRunner.java[28:72] Unable to get class information for
> InitializationError.
--
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-5321) "IOException: Failed to delete repository.xml while trying to rename" during parallel build
Victor Burdejny created MNG-5321: Summary: "IOException: Failed to delete repository.xml while trying to rename" during parallel build Key: MNG-5321 URL: https://jira.codehaus.org/browse/MNG-5321 Project: Maven 2 & 3 Issue Type: Bug Components: General Affects Versions: 3.0.3 Reporter: Victor Burdejny Priority: Minor Attachments: maven-repository-xml-issue.txt The following problem has been found in console when parallel build was used (-T command line parameter): [INFO] --- maven-bundle-plugin:2.3.6:install (default-install) @ my-bundle --- [WARNING] Exception while updating local OBR: IOException org.apache.maven.plugin.MojoExecutionException: IOException at org.apache.felix.obrplugin.ObrUpdate.writeRepositoryXml(ObrUpdate.java:293) at org.apache.felix.obrplugin.ObrInstall.execute(ObrInstall.java:149) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) ... 'stderr' contains the following stacktrace: java.io.IOException: Failed to delete c:\.m2\repository.xml while trying to rename C:\Users\User\AppData\Local\Temp\repository8243840781003249024.xml at org.codehaus.plexus.util.FileUtils.rename(FileUtils.java:2128) at org.apache.felix.obrplugin.ObrUpdate.writeRepositoryXml(ObrUpdate.java:288) ... Full stacktraces are provided in the attachment. I did not find any problems that it causes for the build, but I suspect that such problems might exist. The problem itself is (I suspect) a trivial race condition. -- 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] (MRRESOURCES-58) 'process' goal fails with NPE at the root of a reactor if child modules use version ranges for dependencies
[ https://jira.codehaus.org/browse/MRRESOURCES-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305278#comment-305278 ] Sergei Ivanov commented on MRRESOURCES-58: -- Can anybody please have a look at the patch and apply it to the trunk? We have successfully been using a patched version internally for a few months now. > 'process' goal fails with NPE at the root of a reactor if child modules use > version ranges for dependencies > --- > > Key: MRRESOURCES-58 > URL: https://jira.codehaus.org/browse/MRRESOURCES-58 > Project: Maven 2.x Remote Resources Plugin > Issue Type: Bug >Affects Versions: 1.2.1, 1.3 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) > Java version: 1.6.0_25, vendor: Sun Microsystems Inc. > Default locale: en_GB, platform encoding: UTF-8 > OS name: "windows xp", version: "5.1", arch: "x86", family: "windows" >Reporter: Sergei Ivanov > Attachments: test-reactor-version-ranges.zip, > version-ranges-bugfix.patch, version-ranges-bugfix-v2.patch > > > When the maven-remote-resources-plugin:process goal is integrated into the > lifecycle of a parent project in a multi-module reactor build, the goal fails > with an NPE if dependency version ranges are used in the child modules. > Additionally, "runOnlyAtExecutionRoot" option needs to be set to true in > order to recreate the problem. Please see the attached test project that > demonstrates the problem. > Full exception trace is as follows: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:process > (process-remote-resources) on project test-parent: Execution > process-remote-resources of goal > org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:process failed. > NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:process > (process-remote-resources) on project test-parent: Execution > process-remote-resources of goal > org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:process failed. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > at org.codehaus.classworlds.Launcher.main(Launcher.java:47) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution > process-remote-resources of goal > org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:process failed. > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) > at > org.apache.maven.lifecycle.int
[jira] (MRELEASE-783) release:update-versions should not need SCM config
[
https://jira.codehaus.org/browse/MRELEASE-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305279#comment-305279
]
Robert Scholte commented on MRELEASE-783:
-
{quote}org.apache.maven.plugins:maven-release-plugin:2.0:update-versions{quote}
Could you upgrade to version 2.3.2, because I'm pretty sure this is already
fixed.
> release:update-versions should not need SCM config
> --
>
> Key: MRELEASE-783
> URL: https://jira.codehaus.org/browse/MRELEASE-783
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
>Reporter: Ondrej Zizka
>
> Currently, on a project without configured, {{mvn
> release:update-versions}} ends up with:
> {code}
> Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.0:update-versions
> (default-cli) on project wicketstuff-dojo: Missing required setting: scm
> connection or developerConnection must be specified.
> {code}
> Updating versions recursively definitely does not need SCM.
> Could this restriction be removed? Thanks.
--
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] (MDEP-364) 'tree' goal fails with an NPE if a project uses version ranges for dependencies
[
https://jira.codehaus.org/browse/MDEP-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305277#comment-305277
]
Sergei Ivanov commented on MDEP-364:
Looking for similar symptoms on the internet, I ran into a problem submitted by
myself some time ago against the maven-resources plugin:
http://jira.codehaus.org/browse/MRRESOURCES-58
I managed to get down to the root cause that time and prepared a patch, and I
wonder if the two issues are related and a similar approach could fix the
dependency plugin.
> 'tree' goal fails with an NPE if a project uses version ranges for
> dependencies
> ---
>
> Key: MDEP-364
> URL: https://jira.codehaus.org/browse/MDEP-364
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: tree
>Affects Versions: 2.4
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+)
> Maven home: /opt/app/eti/tools/apache-maven-3.0.4
> Java version: 1.6.0_15, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: ANSI_X3.4-1968
> OS name: "linux", version: "2.6.9-42.0.8.elsmp", arch: "amd64", family: "unix"
>Reporter: Sergei Ivanov
>
> We have bound execution of _dependency:tree_ to the _verify_ phase in the
> parent POM for all of our projects. That way, maven always dumps a complete
> tree of dependencies for a project after it's been fully packaged and before
> it's installed/deployed.
> The plugin set-up looks like this:
> {code:lang=xml}
>
> true
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.4
>
>
>
> display-dependency-tree
> verify
>
> tree
>
>
>
>
> {code}
> Today it failed sporadically with an NPE during a routine CI build in Jenkins.
> Maven options for Jenkins:
> {noformat}-B --settings /home//.m2/settings-jenkins-releases.xml -U
> clean verify{noformat}
> The stack trace is below:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-dependency-plugin:2.4:tree
> (display-dependency-tree) on project liquidity-common-server: Execution
> display-dependency-tree of goal
> org.apache.maven.plugins:maven-dependency-plugin:2.4:tree failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
> at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
> at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:287)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> display-de
[jira] (MDEP-364) 'tree' goal fails with an NPE if a project uses version ranges for dependencies
Sergei Ivanov created MDEP-364:
--
Summary: 'tree' goal fails with an NPE if a project uses version
ranges for dependencies
Key: MDEP-364
URL: https://jira.codehaus.org/browse/MDEP-364
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: tree
Affects Versions: 2.4
Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+)
Maven home: /opt/app/eti/tools/apache-maven-3.0.4
Java version: 1.6.0_15, vendor: Sun Microsystems Inc.
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: "linux", version: "2.6.9-42.0.8.elsmp", arch: "amd64", family: "unix"
Reporter: Sergei Ivanov
We have bound execution of _dependency:tree_ to the _verify_ phase in the
parent POM for all of our projects. That way, maven always dumps a complete
tree of dependencies for a project after it's been fully packaged and before
it's installed/deployed.
The plugin set-up looks like this:
{code:lang=xml}
true
org.apache.maven.plugins
maven-dependency-plugin
2.4
display-dependency-tree
verify
tree
{code}
Today it failed sporadically with an NPE during a routine CI build in Jenkins.
Maven options for Jenkins:
{noformat}-B --settings /home//.m2/settings-jenkins-releases.xml -U
clean verify{noformat}
The stack trace is below:
{noformat}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:2.4:tree
(display-dependency-tree) on project liquidity-common-server: Execution
display-dependency-tree of goal
org.apache.maven.plugins:maven-dependency-plugin:2.4:tree failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at
org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
display-dependency-tree of goal
org.apache.maven.plugins:maven-dependency-plugin:2.4:tree failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 27 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.artifact.DefaultArtifact.equals(DefaultArtifact.java:344)
at
org.apache.maven.shared.dependency.tree.DependencyNode.equals(DependencyNode.java:811)
at
org.apache.maven.shared.dependency.tree.filter.AncestorOrSelfDependencyNodeFilter.isAncestorOrSelf(AncestorOrSelfDependencyNodeFilter.java:103)
at
org.apache.maven.shar
[jira] (MRELEASE-785) Arguments containing spaces and quotes cause the forked maven process to fail
[
https://jira.codehaus.org/browse/MRELEASE-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-785:
Description:
The following config:
{code:xml}
maven-release-plugin
forked-path
false
-Dgpg.passphrase="a phrase 'containing' quotes and
spaces"
{code}
causes the forked clean verify to fail. This is preventing me using my gpg key
as part of an automated release process.
This is due to a bug in Plexus Utils which I have raised as issue 152
PLXUTILS-152, and for which I have raised a pull request here:
https://github.com/sonatype/plexus-utils/pull/5. I am raising an issue on the
release plugin as when/if a fixed version of plexus utils is released the maven
release plugin will need to upgrade to this new version to benefit.
was:
The following config:
maven-release-plugin
forked-path
false
-Dgpg.passphrase="a phrase 'containing' quotes and
spaces"
causes the forked clean verify to fail. This is preventing me using my gpg key
as part of an automated release process.
This is due to a bug in Plexus Utils which I have raised as issue 152
http://jira.codehaus.org/browse/PLXUTILS-152, and for which I have raised a
pull request here: https://github.com/sonatype/plexus-utils/pull/5. I am
raising an issue on the release plugin as when/if a fixed version of plexus
utils is released the maven release plugin will need to upgrade to this new
version to benefit.
> Arguments containing spaces and quotes cause the forked maven process to fail
> -
>
> Key: MRELEASE-785
> URL: https://jira.codehaus.org/browse/MRELEASE-785
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.3.2
> Environment: *nix
>Reporter: Rob Elliot
>
> The following config:
> {code:xml}
>
> maven-release-plugin
>
> forked-path
> false
> -Dgpg.passphrase="a phrase 'containing' quotes and
> spaces"
>
>
> {code}
> causes the forked clean verify to fail. This is preventing me using my gpg
> key as part of an automated release process.
> This is due to a bug in Plexus Utils which I have raised as issue 152
> PLXUTILS-152, and for which I have raised a pull request here:
> https://github.com/sonatype/plexus-utils/pull/5. I am raising an issue on
> the release plugin as when/if a fixed version of plexus utils is released the
> maven release plugin will need to upgrade to this new version to benefit.
--
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
