[jira] (MCHANGES-283) Add GitHub reporter
Bryan Baugher created MCHANGES-283: -- Summary: Add GitHub reporter Key: MCHANGES-283 URL: https://jira.codehaus.org/browse/MCHANGES-283 Project: Maven 2.x Changes Plugin Issue Type: New Feature Reporter: Bryan Baugher Attachments: MCHANGES-GitHubReport.patch Maven changes plugin should support downloading issues from github repos and creating a github report. -- 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] (MANTTASKS-157) Manven-ant-tasks do not use servers list from maven conf
[ https://jira.codehaus.org/browse/MANTTASKS-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Gilbode updated MANTTASKS-157: --- Attachment: manttasks-157.diff > Manven-ant-tasks do not use servers list from maven conf > > > Key: MANTTASKS-157 > URL: https://jira.codehaus.org/browse/MANTTASKS-157 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.10 >Reporter: Krashan Brahmanjara > Attachments: manttasks-157.diff, manttasks-157.diff > > > I got simply ant and pom project. Settings file for maven 2.1 contains list > of mirror servers. > If I compile project by mvn package everything works ok - artifacts are > downloaded > if I compile the same project by ant and maven-ant-tasks some artifacts are > not downloaded. it looks like the mirrors list are sometimes ignored. > Current workaroud is add to pom.xml repository entries which are duplicate of > mirrors from maven configuration. > maven settings > > > krokodylowy3 > http://krokodylowy3.webpark.pl/maven/m2/repository > central > > > Apache.releases > https://repository.apache.org/content/repositories/releases/ > central > > > Apache.snapshots > https://repository.apache.org/content/repositories/snapshots/ > central > > > repository.jboss.org > http://repository.jboss.org/maven2 > central > > > repo1.maven.org > http://repo1.maven.org/maven2 > * > > > workaround > > > thirdparty > krokodylowy3 thirdparty > > http://krokodylowy3.webpark.pl/maven/m2/repository > > > jboss > jboss thirdparty > http://repository.jboss.org/maven2 > > -- 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] (MANTTASKS-157) Manven-ant-tasks do not use servers list from maven conf
[ https://jira.codehaus.org/browse/MANTTASKS-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Gilbode updated MANTTASKS-157: --- Attachment: manttasks-157.diff Patch based on Nikolay's suggestion, seems to resolve the issue. > Manven-ant-tasks do not use servers list from maven conf > > > Key: MANTTASKS-157 > URL: https://jira.codehaus.org/browse/MANTTASKS-157 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.10 >Reporter: Krashan Brahmanjara > Attachments: manttasks-157.diff > > > I got simply ant and pom project. Settings file for maven 2.1 contains list > of mirror servers. > If I compile project by mvn package everything works ok - artifacts are > downloaded > if I compile the same project by ant and maven-ant-tasks some artifacts are > not downloaded. it looks like the mirrors list are sometimes ignored. > Current workaroud is add to pom.xml repository entries which are duplicate of > mirrors from maven configuration. > maven settings > > > krokodylowy3 > http://krokodylowy3.webpark.pl/maven/m2/repository > central > > > Apache.releases > https://repository.apache.org/content/repositories/releases/ > central > > > Apache.snapshots > https://repository.apache.org/content/repositories/snapshots/ > central > > > repository.jboss.org > http://repository.jboss.org/maven2 > central > > > repo1.maven.org > http://repo1.maven.org/maven2 > * > > > workaround > > > thirdparty > krokodylowy3 thirdparty > > http://krokodylowy3.webpark.pl/maven/m2/repository > > > jboss > jboss thirdparty > http://repository.jboss.org/maven2 > > -- 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] (MANTTASKS-157) Manven-ant-tasks do not use servers list from maven conf
[ https://jira.codehaus.org/browse/MANTTASKS-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301685#comment-301685 ] Mike Gilbode commented on MANTTASKS-157: I had the same issue where my mirror was not being used & downloads were always attemted from central. Nikolay's suggestion worked for me too. > Manven-ant-tasks do not use servers list from maven conf > > > Key: MANTTASKS-157 > URL: https://jira.codehaus.org/browse/MANTTASKS-157 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.10 >Reporter: Krashan Brahmanjara > > I got simply ant and pom project. Settings file for maven 2.1 contains list > of mirror servers. > If I compile project by mvn package everything works ok - artifacts are > downloaded > if I compile the same project by ant and maven-ant-tasks some artifacts are > not downloaded. it looks like the mirrors list are sometimes ignored. > Current workaroud is add to pom.xml repository entries which are duplicate of > mirrors from maven configuration. > maven settings > > > krokodylowy3 > http://krokodylowy3.webpark.pl/maven/m2/repository > central > > > Apache.releases > https://repository.apache.org/content/repositories/releases/ > central > > > Apache.snapshots > https://repository.apache.org/content/repositories/snapshots/ > central > > > repository.jboss.org > http://repository.jboss.org/maven2 > central > > > repo1.maven.org > http://repo1.maven.org/maven2 > * > > > workaround > > > thirdparty > krokodylowy3 thirdparty > > http://krokodylowy3.webpark.pl/maven/m2/repository > > > jboss > jboss thirdparty > http://repository.jboss.org/maven2 > > -- 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-156) Prompt for customizing commit comment during release preparation
[
https://jira.codehaus.org/browse/MRELEASE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301678#comment-301678
]
Robert Scholte commented on MRELEASE-156:
-
FAQ improved in [r1352705|http://svn.apache.org/viewvc?rev=1352705&view=rev]
@Przemyslaw: the FAQ-entry only talked about the commandline option. {{ALT 10}}
wasn't meant as literal of course, but as {{ALT}}-key together with the {{1}}
and {{0}}.
Anyhow, the ${line.separator} is probably a better solution, which works for
both configuration and commandline.
> Prompt for customizing commit comment during release preparation
>
>
> Key: MRELEASE-156
> URL: https://jira.codehaus.org/browse/MRELEASE-156
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: prepare
>Affects Versions: 2.0-beta-4
>Reporter: Dário Oliveros
>Assignee: Robert Scholte
>
> Hi there,
> I've been trying to use maven-release-plugin to prepare a release, but
> whenever I do that, it fails since I have a SVN precommit hook that
> integrates with an issue tracking system which in turn waits for a comment
> containing an issue number. Since release plugin adds its own comment, such
> as "[maven-release-plugin] prepare release ...", this integration fails. So
> I was wondering if this could be prompted in the same way for the release and
> next development iteration versions.
> Thanks,
> Dário
--
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] (SCM-680) Changelog parse date fails
[
https://jira.codehaus.org/browse/SCM-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Bueno Postacchini updated SCM-680:
---
Attachment: MNG-SCM-680-maven-scm-provider-hg.patch
The correct correction. =P
> Changelog parse date fails
> --
>
> Key: SCM-680
> URL: https://jira.codehaus.org/browse/SCM-680
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-mercurial (hg)
>Affects Versions: 1.7
> Environment: Debian Linux, possibly any other.
>Reporter: Leonardo Bueno Postacchini
> Attachments: MNG-SCM-680-maven-scm-provider-hg.patch,
> MNG-SCM-maven-scm-provider-hg.patch
>
>
> When system locale disagrees with maven locale the date becomes unparsable.
> The patch changes the time format used by the changelog to comply with
> ISO8601 date format and changes the mercurial command log call to template
> instead of verbose to gain control over the date format output and uses
> {date|isdodatesec} so that the command becomes locale agnostic.
--
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] (SCM-680) Changelog parse date fails
Leonardo Bueno Postacchini created SCM-680:
--
Summary: Changelog parse date fails
Key: SCM-680
URL: https://jira.codehaus.org/browse/SCM-680
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-mercurial (hg)
Affects Versions: 1.7
Environment: Debian Linux, possibly any other.
Reporter: Leonardo Bueno Postacchini
Attachments: MNG-SCM-maven-scm-provider-hg.patch
When system locale disagrees with maven locale the date becomes unparsable.
The patch changes the time format used by the changelog to comply with ISO8601
date format and changes the mercurial command log call to template instead of
verbose to gain control over the date format output and uses {date|isdodatesec}
so that the command becomes locale agnostic.
--
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-776) use maven-plugin-tools' java 5 annotations
Robert Scholte created MRELEASE-776: --- Summary: use maven-plugin-tools' java 5 annotations Key: MRELEASE-776 URL: https://jira.codehaus.org/browse/MRELEASE-776 Project: Maven 2.x Release Plugin Issue Type: Task Components: branch, clean, perform, prepare, prepare-with-pom, rollback, stage, update-versions Reporter: Robert Scholte -- 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] (MRESOURCES-165) use maven-plugin-tools' java 5 annotations
[ https://jira.codehaus.org/browse/MRESOURCES-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRESOURCES-165. - Resolution: Duplicate > use maven-plugin-tools' java 5 annotations > -- > > Key: MRESOURCES-165 > URL: https://jira.codehaus.org/browse/MRESOURCES-165 > Project: Maven 2.x Resources Plugin > Issue Type: Task >Affects Versions: 2.5 >Reporter: Herve Boutemy > -- 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] (MRESOURCES-167) use new maven plugins annotations.
[ https://jira.codehaus.org/browse/MRESOURCES-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MRESOURCES-167: -- Issue Type: Task (was: Bug) > use new maven plugins annotations. > -- > > Key: MRESOURCES-167 > URL: https://jira.codehaus.org/browse/MRESOURCES-167 > Project: Maven 2.x Resources Plugin > Issue Type: Task >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.6 > > -- 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-565) CLONE -Updating of dependencyManagement inconsistent with updating of dependencies with regard to SNAPSHOTs
[
https://jira.codehaus.org/browse/MRELEASE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301667#comment-301667
]
Robert Scholte commented on MRELEASE-565:
-
James,
could you create a sample project for me which reflects this issue.
Take a look at
https://svn.apache.org/repos/asf/maven/release/trunk/maven-release-manager/src/test/resources/projects/
for some examples.
I think we need an example for both {{rewrite-for-release}} and
{{rewrite-for-development}}.
Once reproduced with a valid example it should be much easier for me to fix
this.
> CLONE -Updating of dependencyManagement inconsistent with updating of
> dependencies with regard to SNAPSHOTs
> ---
>
> Key: MRELEASE-565
> URL: https://jira.codehaus.org/browse/MRELEASE-565
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: maven 2.0.4, win XP
>Reporter: Carlo de Wolf
>Assignee: Emmanuel Venisse
>
> The mechanism in release:prepare for creating the new development version of
> POM's handles snapshots that are part of the current reactor build
> differently for dependencyManagement and for dependencies.
> A snapshot version in a dependencies section will be updated to the next
> development version whereas one in dependencyManagement won't.
> The attached patch will change this behavior. It will update a snapshot
> version under dependencyManagement if and only if it is part of the current
> reactor build.
> Note that dependencies cannot contain snapshot versions that are not part of
> the current reactor, but dependencyManagement can. I suggest to forbid this
> too.
> A second suggestion is to introduce a parameter to control the updating of
> snapshot dependencies in both dependencyManagement and dependencies sections.
> Either leave them at the released version or update them to the new
> development version. This touches on the discussion in MRELEASE-36 about the
> developer having to knowingly choose to use a new development version. I
> would be fine with using a parameter to select the behavior as obtained with
> my patch. My central point is that dependencyManagement and dependencies
> snapshots should behave the same.
--
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-679) CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of project/trunk
[
https://jira.codehaus.org/browse/MRELEASE-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301661#comment-301661
]
Robert Scholte commented on MRELEASE-679:
-
@Adrian,
I'd like to know in which version it was solved. Could you try to reproduce
this issue with version {{2.3.1}}, {{2.3}} and {{2.2.2}} as well?
> CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/
> instead of project/trunk
> --
>
> Key: MRELEASE-679
> URL: https://jira.codehaus.org/browse/MRELEASE-679
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0
> Environment: Maven 2.2.1
>Reporter: Claus Gebert
>Priority: Critical
>
> We have switched to the release plug-in 2.0 and are using the prepare goal as
> we did before using version 2.0-beta-9. Unfortunately, the tag which is now
> created is copied from the project level, and from the trunk. With version
> 2.0-beta-9, the tag was correctly copied from the trunk.
> With 2.0-beta-9:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- pom.xml
> |-- src/
> {noformat}
> With 2.0:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- trunk/
>|-- pom.xml
>|-- src/
> |-- tags/
> |-- branches/
> {noformat}
> Our _pom.xml_ SCM information is declared as follow:
> {noformat}
>
>
> scm:svn:svn://host/path/project/trunk
>
> {noformat}
--
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] (MJAR-156) Classpath created in manifest contains timestamp instead of the suffix "-SNAPSHOT"
Markus KARG created MJAR-156:
Summary: Classpath created in manifest contains timestamp instead
of the suffix "-SNAPSHOT"
Key: MJAR-156
URL: https://jira.codehaus.org/browse/MJAR-156
Project: Maven 2.x JAR Plugin
Issue Type: Bug
Affects Versions: 2.4, 2.3.2
Environment: Win7 Pro SP1 (64 Bit), JDK 1.6.0_26 (32 Bit)
Reporter: Markus KARG
Attachments: Sample.zip
Sometimes the JAR packager replaces a dependency's "-SNAPSHOT" suffix by a
timestamp when calculating a corresponding "Class-Path:"-entry for all
dependencies into the MANIFEST.MF file of the packaged JAR. This is
problematic, as typically the dependency shipped together with the created JAR
will NOT be renamed, but shipped WITH the suffix "-SNAPSHOT". The created JAR
will at runtime not find the JAR due to the wrong suffix then
("ClassNotFoundException" will happen for all content in the dependency,
obviously). Strange but true, this seem to happen only for SOME JARs and only
in SOME particular situations, but I was not able to identify the root causes.
Attached is a tiny MVN project containing a pom that will produce this
behaviour.
* How to demonstrate:
- Unpack attached JAR
- Manually deploy the dependency "webdav-jaxrs-1.2-SNAPSHOT.jar" found in
subfolder "install-this-in-repo" into the local repository.
- mvn clean package
- "target\sample-1.0.0-SNAPSHOT.jar" contains wrong MANIFEST.MF Class-Path:
entry now:
Class-Path: webdav-jaxrs-1.2-20120621.141509-35.jar jsr311-api-1.1.1.jar
(Sample output contained in ZIP\target!)
Obviously "-SNAPSHOT" was replaced by "20120621.141509-35", what induces the
problem that the actual dependency is not found, as its file ends still on
"-SNAPSHOT" (by intention!). This scenario typically happens when both files
end up in an EAR for example.
* Expected Result:
- Class-Path: webdav-jaxrs-1.2-SNAPSHOT.jar jsr311-api-1.1.1.jar
* Actual Result:
- Class-Path: webdav-jaxrs-1.2-20120621.141509-35.jar jsr311-api-1.1.1.jar
* Workaround:
- Provide a static MANIFEST.MF file. Drawback: Changing dependency induces
manual corrections to the static file.
- Fix the entry manually after each build. Drawback: Hard to automate 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] (MRELEASE-156) Prompt for customizing commit comment during release preparation
[ https://jira.codehaus.org/browse/MRELEASE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301649#comment-301649 ] Przemyslaw Wojnowski commented on MRELEASE-156: --- Could you add an example to the FAQ? I've such configuration: org.apache.maven.plugins maven-release-plugin 2.3.2 ABCD-1234 ALT 10 And when I issue "mvn release:prepare -DdryRun=true" it doesn't show any new line: [INFO] Full run would be commit 4 files with message: 'ABCD-1234 ALT 10prepare release my-project-1.0.1' > Prompt for customizing commit comment during release preparation > > > Key: MRELEASE-156 > URL: https://jira.codehaus.org/browse/MRELEASE-156 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare >Affects Versions: 2.0-beta-4 >Reporter: Dário Oliveros >Assignee: Robert Scholte > > Hi there, > I've been trying to use maven-release-plugin to prepare a release, but > whenever I do that, it fails since I have a SVN precommit hook that > integrates with an issue tracking system which in turn waits for a comment > containing an issue number. Since release plugin adds its own comment, such > as "[maven-release-plugin] prepare release ...", this integration fails. So > I was wondering if this could be prompted in the same way for the release and > next development iteration versions. > Thanks, > Dário -- 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] (MCHANGES-282) New parameter releaseDateLocale in changes-check goal
[
https://jira.codehaus.org/browse/MCHANGES-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Prochazka updated MCHANGES-282:
Attachment: changes-check.patch
Patch + unit test changes.
> New parameter releaseDateLocale in changes-check goal
> -
>
> Key: MCHANGES-282
> URL: https://jira.codehaus.org/browse/MCHANGES-282
> Project: Maven 2.x Changes Plugin
> Issue Type: Improvement
>Affects Versions: 2.7.1
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: D:\usr\share\java\apache-maven
> Java version: 1.6.0_31, vendor: Sun Microsystems Inc.
> Java home: D:\usr\share\java\jdk\jre
> Default locale: cs_CZ, platform encoding: Cp1250
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Petr Prochazka
>Priority: Minor
> Attachments: changes-check.patch
>
>
> I have defined parameter {code}releaseDateFormat=E MMM dd {code} and
> release dates are defined with English locale in changes.xml.
> If I run maven with other locale settings, then changes-check goal failed
> that release date has wrong format.
> Workaround for this behaivour is, defines english locale in
> {code}MAVEN_OPTS=-Duser.language=en -Duser.region=US{code}, but better is
> define locale in configuration.
> {code:xml}
> en_US
> {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] (MCHANGES-282) New parameter releaseDateLocale in changes-check goal
Petr Prochazka created MCHANGES-282:
---
Summary: New parameter releaseDateLocale in changes-check goal
Key: MCHANGES-282
URL: https://jira.codehaus.org/browse/MCHANGES-282
Project: Maven 2.x Changes Plugin
Issue Type: Improvement
Affects Versions: 2.7.1
Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: D:\usr\share\java\apache-maven
Java version: 1.6.0_31, vendor: Sun Microsystems Inc.
Java home: D:\usr\share\java\jdk\jre
Default locale: cs_CZ, platform encoding: Cp1250
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Petr Prochazka
Priority: Minor
I have defined parameter {code}releaseDateFormat=E MMM dd {code} and
release dates are defined with English locale in changes.xml.
If I run maven with other locale settings, then changes-check goal failed that
release date has wrong format.
Workaround for this behaivour is, defines english locale in
{code}MAVEN_OPTS=-Duser.language=en -Duser.region=US{code}, but better is
define locale in configuration.
{code:xml}
en_US
{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] (SCM-657) SvnExeExportCommand with revision malfunctions for moved/deleted files
[ https://jira.codehaus.org/browse/SCM-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] adam.kopecky updated SCM-657: - Attachment: patch > SvnExeExportCommand with revision malfunctions for moved/deleted files > --- > > Key: SCM-657 > URL: https://jira.codehaus.org/browse/SCM-657 > Project: Maven SCM > Issue Type: Bug > Environment: svn, version 1.6.17 (r1128011) >compiled Nov 19 2011, 08:40:40 >Reporter: adam.kopecky > Attachments: fixed_method.txt, patch > > > According to http://subversion.tigris.org/issues/show_bug.cgi?id=2163, which > is marked 'INVALID' @revision must be used instead of -r revision, otherwise > export does not find specified file. > Attached is a fixed implementation of createCommandLine method of > org.apache.maven.scm.provider.svn.svnexe.command.export.SvnExeExportCommand -- 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] (SCM-657) SvnExeExportCommand with revision malfunctions for moved/deleted files
[ https://jira.codehaus.org/browse/SCM-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301629#comment-301629 ] adam.kopecky commented on SCM-657: -- Sorry, i am behind some facist corporate proxy. So i am unable to checkout your project. Ordinary diff-patch attached. The same bug propably applies to all svn commands. (svn list per sure). > SvnExeExportCommand with revision malfunctions for moved/deleted files > --- > > Key: SCM-657 > URL: https://jira.codehaus.org/browse/SCM-657 > Project: Maven SCM > Issue Type: Bug > Environment: svn, version 1.6.17 (r1128011) >compiled Nov 19 2011, 08:40:40 >Reporter: adam.kopecky > Attachments: fixed_method.txt, patch > > > According to http://subversion.tigris.org/issues/show_bug.cgi?id=2163, which > is marked 'INVALID' @revision must be used instead of -r revision, otherwise > export does not find specified file. > Attached is a fixed implementation of createCommandLine method of > org.apache.maven.scm.provider.svn.svnexe.command.export.SvnExeExportCommand -- 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-876) surefire-junit47 does not work in an OSGi classloader environment
[ https://jira.codehaus.org/browse/SUREFIRE-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301621#comment-301621 ] Jan Sievers commented on SUREFIRE-876: -- patch includes a unit test... > surefire-junit47 does not work in an OSGi classloader environment > - > > Key: SUREFIRE-876 > URL: https://jira.codehaus.org/browse/SUREFIRE-876 > Project: Maven Surefire > Issue Type: Improvement > Components: classloading, Junit 4.7+ (parallel) support >Affects Versions: 2.10 >Reporter: Jan Sievers > > while trying to port JUnitCoreProvider to tycho, I noticed that it fails with > an NPE when run inside an OSGi environment. > The root cause is really JUnit bug > https://github.com/KentBeck/junit/issues/364 > JUnit uses Class.forName() to load the test class which assumes the JUnit > classloader can always load test classes, which is not true in an OSGi > classloader environment. > While this should be fixed in JUnit, it's easy to work around this issue in > surefire. > It's not necessary to use the offending > org.junit.runner.Description.getTestClass() in > JUnitCoreRunListener.fillTestCountMap(). We can use String getClassName() > instead to circumvent classloading issues as we only need the class name > anyway. > I will attach a patch. -- 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-679) CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of project/trunk
[
https://jira.codehaus.org/browse/MRELEASE-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301617#comment-301617
]
Adrian Pillinger commented on MRELEASE-679:
---
I've just experienced this same issue. When I then updated my plugin to use
org.apache.maven.plugins
maven-release-plugin
2.3.2
the issue has gone away.
> CLONE -release:prepare 2.0 goal tags at the wrong level, tagging project/
> instead of project/trunk
> --
>
> Key: MRELEASE-679
> URL: https://jira.codehaus.org/browse/MRELEASE-679
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0
> Environment: Maven 2.2.1
>Reporter: Claus Gebert
>Priority: Critical
>
> We have switched to the release plug-in 2.0 and are using the prepare goal as
> we did before using version 2.0-beta-9. Unfortunately, the tag which is now
> created is copied from the project level, and from the trunk. With version
> 2.0-beta-9, the tag was correctly copied from the trunk.
> With 2.0-beta-9:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- pom.xml
> |-- src/
> {noformat}
> With 2.0:
> {noformat}
> /project
>|-- trunk/
> |-- pom.xml
> |-- src/
>|-- tags/
> |-- 4.0.1/ (<-- copied from trunk
> |-- trunk/
>|-- pom.xml
>|-- src/
> |-- tags/
> |-- branches/
> {noformat}
> Our _pom.xml_ SCM information is declared as follow:
> {noformat}
>
>
> scm:svn:svn://host/path/project/trunk
>
> {noformat}
--
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] (MCOMPILER-165) Child modules don't seem to be able to use a different compilerId to their parent modules when built from the parent POM.
[
https://jira.codehaus.org/browse/MCOMPILER-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301612#comment-301612
]
Joerg Schaible commented on MCOMPILER-165:
--
For M2 this does not matter, the plugin is loaded once and once only.
> Child modules don't seem to be able to use a different compilerId to their
> parent modules when built from the parent POM.
> -
>
> Key: MCOMPILER-165
> URL: https://jira.codehaus.org/browse/MCOMPILER-165
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2
>Reporter: Edd grant
> Attachments: multiple-pom-mixed-java-groovy-project-test.zip
>
>
> I have a mixed Java/ Groovy project which is split over several Maven
> modules, all of which have a common parent module. In the parent POM I
> specify some basic common options for the {{maven-compiler-plugin}} (see
> example 1 below). The idea being that in my child modules I can either simple
> use this configuration by specifying the plugin with no further configuration
> (example 2), or I can override this configuration if I have specific
> requirements (for example switching the {{compilerId}}) (example 3).
> Example 1 - Parent POM:
> {code}
>
>
>
> maven-compiler-plugin
> 2.3.2
>
> 1.6
> 1.6
>
>
>
>
> {code}
> Example 2 - Child POM that inherits the parent POM's plugin configuration:
> {code}
>
> maven-compiler-plugin
>
> {code}
> Example 3 - Child POM that specifies a different compilation configuration
> (uses the {{groovy-eclipse-compiler}}) to the parent POM's configuration:
> {code}
>
> maven-compiler-plugin
>
> groovy-eclipse-compiler
> true
> 1.6
> 1.6
>
>
>
> org.codehaus.groovy
> groovy-eclipse-compiler
> 2.6.0-01
>
>
>
> {code}
> Using this configuration everything works fine if I build ({{mvn clean
> install}}) each POM individually, however when I build the project from the
> parent POM compilation of the module with the switched {{compilerId}} fails
> and I get the following error:
> {code}
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] No such compiler 'groovy-eclipse-compiler'.
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: No such compiler
> 'groovy-eclipse-compiler'.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> 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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: No such compiler
> 'groovy-eclipse-compiler'.
> at
> org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:339)
> at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> {code}
> Would be most grateful if someone could look at this as it's causing us a lot
[jira] (MCOMPILER-165) Child modules don't seem to be able to use a different compilerId to their parent modules when built from the parent POM.
[
https://jira.codehaus.org/browse/MCOMPILER-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301608#comment-301608
]
hendra commented on MCOMPILER-165:
--
sorry didn't make it clear enough.
what I mean is using different version of the plugin.
for your case in 'Example 3': instead of "inherit" the version of
maven-compiler-plugin (version 2.3.2) from the parent pom try to use different
version.
example:
{noformat}
maven-compiler-plugin
${other.version}
groovy-eclipse-compiler
true
1.6
1.6
org.codehaus.groovy
groovy-eclipse-compiler
2.6.0-01
{noformat}
cheers.
> Child modules don't seem to be able to use a different compilerId to their
> parent modules when built from the parent POM.
> -
>
> Key: MCOMPILER-165
> URL: https://jira.codehaus.org/browse/MCOMPILER-165
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2
>Reporter: Edd grant
> Attachments: multiple-pom-mixed-java-groovy-project-test.zip
>
>
> I have a mixed Java/ Groovy project which is split over several Maven
> modules, all of which have a common parent module. In the parent POM I
> specify some basic common options for the {{maven-compiler-plugin}} (see
> example 1 below). The idea being that in my child modules I can either simple
> use this configuration by specifying the plugin with no further configuration
> (example 2), or I can override this configuration if I have specific
> requirements (for example switching the {{compilerId}}) (example 3).
> Example 1 - Parent POM:
> {code}
>
>
>
> maven-compiler-plugin
> 2.3.2
>
> 1.6
> 1.6
>
>
>
>
> {code}
> Example 2 - Child POM that inherits the parent POM's plugin configuration:
> {code}
>
> maven-compiler-plugin
>
> {code}
> Example 3 - Child POM that specifies a different compilation configuration
> (uses the {{groovy-eclipse-compiler}}) to the parent POM's configuration:
> {code}
>
> maven-compiler-plugin
>
> groovy-eclipse-compiler
> true
> 1.6
> 1.6
>
>
>
> org.codehaus.groovy
> groovy-eclipse-compiler
> 2.6.0-01
>
>
>
> {code}
> Using this configuration everything works fine if I build ({{mvn clean
> install}}) each POM individually, however when I build the project from the
> parent POM compilation of the module with the switched {{compilerId}} fails
> and I get the following error:
> {code}
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] No such compiler 'groovy-eclipse-compiler'.
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: No such compiler
> 'groovy-eclipse-compiler'.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> 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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: No such compiler
> 'groovy-eclipse-compiler'.
> at
> org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:339)
> at or
[jira] (MCOMPILER-165) Child modules don't seem to be able to use a different compilerId to their parent modules when built from the parent POM.
[
https://jira.codehaus.org/browse/MCOMPILER-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301607#comment-301607
]
Joerg Schaible commented on MCOMPILER-165:
--
It cannot work with M2, since every plugin is loaded once and once only i.e.
the dependencies on POM 3 are completely ignored in a reactor build. You would
have to declare them also in the parent in the pluginMgmt section to make this
work.
M3 uses isolated classloaders for the plugins, therefore it will work.
> Child modules don't seem to be able to use a different compilerId to their
> parent modules when built from the parent POM.
> -
>
> Key: MCOMPILER-165
> URL: https://jira.codehaus.org/browse/MCOMPILER-165
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2
>Reporter: Edd grant
> Attachments: multiple-pom-mixed-java-groovy-project-test.zip
>
>
> I have a mixed Java/ Groovy project which is split over several Maven
> modules, all of which have a common parent module. In the parent POM I
> specify some basic common options for the {{maven-compiler-plugin}} (see
> example 1 below). The idea being that in my child modules I can either simple
> use this configuration by specifying the plugin with no further configuration
> (example 2), or I can override this configuration if I have specific
> requirements (for example switching the {{compilerId}}) (example 3).
> Example 1 - Parent POM:
> {code}
>
>
>
> maven-compiler-plugin
> 2.3.2
>
> 1.6
> 1.6
>
>
>
>
> {code}
> Example 2 - Child POM that inherits the parent POM's plugin configuration:
> {code}
>
> maven-compiler-plugin
>
> {code}
> Example 3 - Child POM that specifies a different compilation configuration
> (uses the {{groovy-eclipse-compiler}}) to the parent POM's configuration:
> {code}
>
> maven-compiler-plugin
>
> groovy-eclipse-compiler
> true
> 1.6
> 1.6
>
>
>
> org.codehaus.groovy
> groovy-eclipse-compiler
> 2.6.0-01
>
>
>
> {code}
> Using this configuration everything works fine if I build ({{mvn clean
> install}}) each POM individually, however when I build the project from the
> parent POM compilation of the module with the switched {{compilerId}} fails
> and I get the following error:
> {code}
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] No such compiler 'groovy-eclipse-compiler'.
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: No such compiler
> 'groovy-eclipse-compiler'.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> 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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: No such compiler
> 'groovy-eclipse-compiler'.
> at
> org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:339)
> at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPl
[jira] (MCOMPILER-165) Child modules don't seem to be able to use a different compilerId to their parent modules when built from the parent POM.
[
https://jira.codehaus.org/browse/MCOMPILER-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301606#comment-301606
]
Edd grant commented on MCOMPILER-165:
-
What exactly do you mean by a 'different maven-compiler-plugin', do you mean a
different {{version}} attribute? Or a different {{compilerId}}? Or something
else? Perhaps I've not explained very well but the fact that the parent POM has
a different compilerId to the child was intentional as it supports my use case
where the default is to use Java compilation, because some things like the
maven-jps-plugin don't work with the {{groovy-eclipse-compiler}} , but where
some child modules can use Groovy.
To be honest, I've long since given up on trying to make this work with Maven 2
since I discovered that it works fine with Maven 3.
> Child modules don't seem to be able to use a different compilerId to their
> parent modules when built from the parent POM.
> -
>
> Key: MCOMPILER-165
> URL: https://jira.codehaus.org/browse/MCOMPILER-165
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2
>Reporter: Edd grant
> Attachments: multiple-pom-mixed-java-groovy-project-test.zip
>
>
> I have a mixed Java/ Groovy project which is split over several Maven
> modules, all of which have a common parent module. In the parent POM I
> specify some basic common options for the {{maven-compiler-plugin}} (see
> example 1 below). The idea being that in my child modules I can either simple
> use this configuration by specifying the plugin with no further configuration
> (example 2), or I can override this configuration if I have specific
> requirements (for example switching the {{compilerId}}) (example 3).
> Example 1 - Parent POM:
> {code}
>
>
>
> maven-compiler-plugin
> 2.3.2
>
> 1.6
> 1.6
>
>
>
>
> {code}
> Example 2 - Child POM that inherits the parent POM's plugin configuration:
> {code}
>
> maven-compiler-plugin
>
> {code}
> Example 3 - Child POM that specifies a different compilation configuration
> (uses the {{groovy-eclipse-compiler}}) to the parent POM's configuration:
> {code}
>
> maven-compiler-plugin
>
> groovy-eclipse-compiler
> true
> 1.6
> 1.6
>
>
>
> org.codehaus.groovy
> groovy-eclipse-compiler
> 2.6.0-01
>
>
>
> {code}
> Using this configuration everything works fine if I build ({{mvn clean
> install}}) each POM individually, however when I build the project from the
> parent POM compilation of the module with the switched {{compilerId}} fails
> and I get the following error:
> {code}
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] No such compiler 'groovy-eclipse-compiler'.
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: No such compiler
> 'groovy-eclipse-compiler'.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> 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)
> Caused by: org.apache.maven.plugin.MojoExecut
[jira] (MPLUGIN-213) NullPointerException in descriptor goal
Tony Chemit created MPLUGIN-213:
---
Summary: NullPointerException in descriptor goal
Key: MPLUGIN-213
URL: https://jira.codehaus.org/browse/MPLUGIN-213
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: maven-plugin-tools-java
Affects Versions: 3.0
Reporter: Tony Chemit
Priority: Blocker
Attachments: patch.diff
I have this definition :
{code}
@Mojo( name = "aggregate-add-third-party", requiresProject = true, aggregator =
true,
defaultPhase = LifecyclePhase.GENERATE_RESOURCES )
@Execute( goal = "add-third-party" )
{code}
And this exeception then while building :
{code}
Caused by: java.lang.NullPointerException
at
org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.toMojoDescriptors(JavaAnnotationsMojoDescriptorExtractor.java:522)
at
org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.execute(JavaAnnotationsMojoDescriptorExtractor.java:110)
at
org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:108)
at
org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:245)
at
org.apache.maven.plugin.plugin.HelpGeneratorMojo.execute(HelpGeneratorMojo.java:88)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
{code}
I had a look to the code and it is normal (I think)
{code}
if ( execute != null )
{
mojoDescriptor.setExecuteGoal( execute.goal() );
mojoDescriptor.setExecuteLifecycle( execute.lifecycle() );
mojoDescriptor.setExecutePhase( execute.phase().id() );
}
{code}
but should be
{code}
if ( execute != null )
{
mojoDescriptor.setExecuteGoal( execute.goal() );
mojoDescriptor.setExecuteLifecycle( execute.lifecycle() );
if ( execute.phase() != null )
{
mojoDescriptor.setExecutePhase( execute.phase().id() );
}
}
{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] (MRESOURCES-167) use new maven plugins annotations.
[ https://jira.codehaus.org/browse/MRESOURCES-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRESOURCES-167. --- Resolution: Fixed > use new maven plugins annotations. > -- > > Key: MRESOURCES-167 > URL: https://jira.codehaus.org/browse/MRESOURCES-167 > Project: Maven 2.x Resources Plugin > Issue Type: Bug >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.6 > > -- 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] (MCOMPILER-165) Child modules don't seem to be able to use a different compilerId to their parent modules when built from the parent POM.
[
https://jira.codehaus.org/browse/MCOMPILER-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301593#comment-301593
]
hendra commented on MCOMPILER-165:
--
Try to use different maven-compiler-plugin from the parent pom.
> Child modules don't seem to be able to use a different compilerId to their
> parent modules when built from the parent POM.
> -
>
> Key: MCOMPILER-165
> URL: https://jira.codehaus.org/browse/MCOMPILER-165
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2
>Reporter: Edd grant
> Attachments: multiple-pom-mixed-java-groovy-project-test.zip
>
>
> I have a mixed Java/ Groovy project which is split over several Maven
> modules, all of which have a common parent module. In the parent POM I
> specify some basic common options for the {{maven-compiler-plugin}} (see
> example 1 below). The idea being that in my child modules I can either simple
> use this configuration by specifying the plugin with no further configuration
> (example 2), or I can override this configuration if I have specific
> requirements (for example switching the {{compilerId}}) (example 3).
> Example 1 - Parent POM:
> {code}
>
>
>
> maven-compiler-plugin
> 2.3.2
>
> 1.6
> 1.6
>
>
>
>
> {code}
> Example 2 - Child POM that inherits the parent POM's plugin configuration:
> {code}
>
> maven-compiler-plugin
>
> {code}
> Example 3 - Child POM that specifies a different compilation configuration
> (uses the {{groovy-eclipse-compiler}}) to the parent POM's configuration:
> {code}
>
> maven-compiler-plugin
>
> groovy-eclipse-compiler
> true
> 1.6
> 1.6
>
>
>
> org.codehaus.groovy
> groovy-eclipse-compiler
> 2.6.0-01
>
>
>
> {code}
> Using this configuration everything works fine if I build ({{mvn clean
> install}}) each POM individually, however when I build the project from the
> parent POM compilation of the module with the switched {{compilerId}} fails
> and I get the following error:
> {code}
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] No such compiler 'groovy-eclipse-compiler'.
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: No such compiler
> 'groovy-eclipse-compiler'.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> 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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: No such compiler
> 'groovy-eclipse-compiler'.
> at
> org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:339)
> at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> {code}
> Would be most grateful if someone could look at this as it's causing us a lot
> of pain. Also intere
