[jira] (MRELEASE-764) Default excludes are not recognized by SVNKit SCM provider
[
https://jira.codehaus.org/browse/MRELEASE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-764:
Description:
Although this was fixed in MRELEASE-759 for Jazz, we still have the same
problem with SVNKit SVM Provider
(http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/). The
logs says something like:
{noformat}
[INFO] [release:prepare {execution: default-cli}]
[INFO] Change the default 'svn' provider implementation to 'javasvn'.
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: **/pom.xml.backup, **/release.properties,
**/pom.xml.branch, **/pom.xml.next, **/pom.xml.releaseBackup, **/pom.xml.tag
[INFO] SVN status directory: /opt/jenkins_home/.jenkins/jobs/Logica
Parent/workspace
log4j:WARN No appenders could be found for logger
(org.apache.commons.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
[JENKINS] Archiving /opt/jenkins_home/.jenkins/jobs/Logica
Parent/workspace/pom.xml to /opt/jenkins_home/.jenkins/jobs/Logica
Parent/modules/com.logica$logica-parent/builds/2012-05-29_15-15-41/archive/com.logica/logica-parent/0.0.8-SNAPSHOT/logica-parent-0.0.8-SNAPSHOT.pom
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Cannot prepare the release because you have local modifications :
[/opt/jenkins_home/.jenkins/jobs/Logica
Parent/workspace/pom.xml.releaseBackup:unknown]
{noformat}
This is clearly a regression, since it worked with the maven-release-plugin 2.2
and earlier.
was:
Although this was fixed in MRELEASE-759 for Jazz, we still have the same
problem with SVNKit SVM Provider
(http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/). The
logs says something like:
[INFO] [release:prepare {execution: default-cli}]
[INFO] Change the default 'svn' provider implementation to 'javasvn'.
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: **/pom.xml.backup, **/release.properties,
**/pom.xml.branch, **/pom.xml.next, **/pom.xml.releaseBackup, **/pom.xml.tag
[INFO] SVN status directory: /opt/jenkins_home/.jenkins/jobs/Logica
Parent/workspace
log4j:WARN No appenders could be found for logger
(org.apache.commons.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
[JENKINS] Archiving /opt/jenkins_home/.jenkins/jobs/Logica
Parent/workspace/pom.xml to /opt/jenkins_home/.jenkins/jobs/Logica
Parent/modules/com.logica$logica-parent/builds/2012-05-29_15-15-41/archive/com.logica/logica-parent/0.0.8-SNAPSHOT/logica-parent-0.0.8-SNAPSHOT.pom
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Cannot prepare the release because you have local modifications :
[/opt/jenkins_home/.jenkins/jobs/Logica
Parent/workspace/pom.xml.releaseBackup:unknown]
This is clearly a regression, since it worked with the maven-release-plugin 2.2
and earlier.
Default excludes are not recognized by SVNKit SCM provider
--
Key: MRELEASE-764
URL: https://jira.codehaus.org/browse/MRELEASE-764
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.3.1
Reporter: Konrad Windszus
Although this was fixed in MRELEASE-759 for Jazz, we still have the same
problem with SVNKit SVM Provider
(http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/).
The logs says something like:
{noformat}
[INFO] [release:prepare {execution: default-cli}]
[INFO] Change the default 'svn' provider implementation to 'javasvn'.
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: **/pom.xml.backup, **/release.properties,
**/pom.xml.branch, **/pom.xml.next, **/pom.xml.releaseBackup, **/pom.xml.tag
[INFO] SVN status directory: /opt/jenkins_home/.jenkins/jobs/Logica
Parent/workspace
log4j:WARN No appenders could be found for logger
(org.apache.commons.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
[JENKINS] Archiving /opt/jenkins_home/.jenkins/jobs/Logica
Parent/workspace/pom.xml to /opt/jenkins_home/.jenkins/jobs/Logica
Parent/modules/com.logica$logica-parent/builds/2012-05-29_15-15-41/archive/com.logica/logica-parent/0.0.8-SNAPSHOT/logica-parent-0.0.8-SNAPSHOT.pom
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Cannot prepare the release because you have local
[jira] (MRELEASE-765) Regression in 2.3: release:update-versions doesn't work anymore
[ https://jira.codehaus.org/browse/MRELEASE-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-765. --- Resolution: Fixed Fix Version/s: 2.4 Assignee: Robert Scholte Fixed in [r1344483|http://svn.apache.org/viewvc?rev=1344483view=rev] Regression in 2.3: release:update-versions doesn't work anymore --- Key: MRELEASE-765 URL: https://jira.codehaus.org/browse/MRELEASE-765 Project: Maven 2.x Release Plugin Issue Type: Bug Components: update-versions Affects Versions: 2.3 Reporter: Lars Beuster Assignee: Robert Scholte Priority: Critical Fix For: 2.4 Attachments: pom.xml Since 2.3/2.3.1 the update-versions goal is broken. It doesn't ask for an new version anymore. Version 2.2.2 did. Simply execute on SNAPSHOT project (with scm-URL) mvn org.apache.maven.plugins:maven-release-plugin:2.2.2:update-versions mvn org.apache.maven.plugins:maven-release-plugin:2.3:update-versions mvn org.apache.maven.plugins:maven-release-plugin:2.3.1:update-versions -- 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-766) release:prepare stores settings.xml in a public directory
[
https://jira.codehaus.org/browse/MRELEASE-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300141#comment-300141
]
Robert Scholte commented on MRELEASE-766:
-
Have you seen this happening or is it just a theory? All {{MavenExecutors}}
contain the following:
{code}
try
{
//
}
finally
{
if ( settingsFile != null settingsFile.exists() !settingsFile.delete() )
{
settingsFile.deleteOnExit();
}
}
{code}
release:prepare stores settings.xml in a public directory
-
Key: MRELEASE-766
URL: https://jira.codehaus.org/browse/MRELEASE-766
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.2.2
Reporter: Joseph Walton
The fix for MRELEASE-577 involves copying {{settings.xml}} into a temporary
directory. On a shared machine, it's possible that users have passwords
configured in this file. Although they should probably have used
{{settings-security.xml}} some will have set file permissions to prevent
other users from reading their settings.
If a build fails the file can be behind in /tmp.
The copy should either be set to world-unreadable before any contents are
written or created in a non-public location.
--
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-763) release:prepare ignores invalid dependencies in inactive profiles
[
https://jira.codehaus.org/browse/MRELEASE-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-763:
Issue Type: Improvement (was: Bug)
I see your point, but this means we have to do all the dependency-resolution of
profiles inside the maven-release-plugin. And not just project-dependencies,
but also plugin-dependencies, report-dependencies, extensions, etc.
Sounds more like an improvement to me.
release:prepare ignores invalid dependencies in inactive profiles
-
Key: MRELEASE-763
URL: https://jira.codehaus.org/browse/MRELEASE-763
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Components: prepare
Affects Versions: 2.3
Reporter: Mark Hobson
{{release:prepare}} completes successfully on projects that contain invalid
dependencies in inactive profiles.
For example, a POM containing the following profile containing a non-existent
dependency will prepare without problems:
{code}
...
profiles
profile
idsilly/id
dependencies
dependency
groupIdsilly/groupId
artifactIdsilly/artifactId
version1.0/version
/dependency
/dependencies
/profile
/profiles
...
{code}
Furthermore, if this dependency was changed to a SNAPSHOT version then it
would still succeed. I would expect {{prepare}} to fail in both cases.
--
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-761) [regression] release:rollback no longer works
[
https://jira.codehaus.org/browse/MRELEASE-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MRELEASE-761:
---
Assignee: Robert Scholte
[regression] release:rollback no longer works
-
Key: MRELEASE-761
URL: https://jira.codehaus.org/browse/MRELEASE-761
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: rollback
Affects Versions: 2.3
Reporter: Mark Hobson
Assignee: Robert Scholte
{{release:rollback}} no longer reverts POM changes.
--
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-761) [regression] release:rollback no longer works
[
https://jira.codehaus.org/browse/MRELEASE-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-761.
---
Resolution: Fixed
Fix Version/s: 2.4
Fixed in [r1344836|http://svn.apache.org/viewvc?rev=1344836view=rev]
[regression] release:rollback no longer works
-
Key: MRELEASE-761
URL: https://jira.codehaus.org/browse/MRELEASE-761
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: rollback
Affects Versions: 2.3
Reporter: Mark Hobson
Assignee: Robert Scholte
Fix For: 2.4
{{release:rollback}} no longer reverts POM changes.
--
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-635) perform does not honor updateWorkingCopiesVersion setting
[
https://jira.codehaus.org/browse/MRELEASE-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300145#comment-300145
]
Robert Scholte commented on MRELEASE-635:
-
I guess you meant {{release:prepare}}, right?
perform does not honor updateWorkingCopiesVersion setting
-
Key: MRELEASE-635
URL: https://jira.codehaus.org/browse/MRELEASE-635
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.1
Reporter: Scott Carey
release:perform modifies the working copies version when configured not to.
This was a tag directly from trunk.
configuration
autoVersionSubmodulestrue/autoVersionSubmodules
remoteTaggingfalse/remoteTagging
suppressCommitBeforeTagtrue/suppressCommitBeforeTag
suppressCommitBeforeBranchtrue/suppressCommitBeforeBranch
updateBranchVersionstrue/updateBranchVersions
updateWorkingCopyVersionsfalse/updateWorkingCopyVersions
/configuration
Happens in both dryRun mode and normal.
After a non-dryRun pom.xml.releaseBackup files are left behind as well.
The desired behavior is to leave the working copy alone and only modify the
tag. Currently, with suppressCommitBeforeTag true, this is possible by
reverting the local changes left behind by running release:perform.
--
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-760) updateWorkingCopyVersions=false still bumps up pom versions to next development version
[ https://jira.codehaus.org/browse/MRELEASE-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-760. --- Resolution: Fixed Fix Version/s: 2.4 Assignee: Robert Scholte Fixed in [r1344903|http://svn.apache.org/viewvc?rev=1344903view=rev] updateWorkingCopyVersions=false still bumps up pom versions to next development version --- Key: MRELEASE-760 URL: https://jira.codehaus.org/browse/MRELEASE-760 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.3 Reporter: Joeri Leemans Assignee: Robert Scholte Fix For: 2.4 Attachments: maven-release-plugin-testcase.zip The flag updateWorkingCopyVersions (more specifically with value false) is not handled correctly. Attached project is a simple Maven project with version 1.0-SNAPSHOT, depending on version 2.3 of the release plugin. It is configured with dryRun=true and updateWorkingCopyVersions=false. When running mvn:prepare (and accepting the versions that are proposed), you'll see that pom.xml.next file contains 1.1-SNAPSHOT (the next development version) instead of 1.0 (the tagged version). -- 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-674) release plugin converts explicit version to snapshot
[
https://jira.codehaus.org/browse/MRELEASE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reopened MRELEASE-674:
-
release plugin converts explicit version to snapshot
-
Key: MRELEASE-674
URL: https://jira.codehaus.org/browse/MRELEASE-674
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: update-versions
Affects Versions: 2.1
Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
Java version: 1.6.0_23, vendor: Sun Microsystems Inc.
Java home: i:\tools\jdk\1.6.0_23\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: windows xp, version: 5.1, arch: x86, family: windows
Reporter: Bernd Mau
Assignee: Robert Scholte
Fix For: 2.4
Attachments: MapVersionPhase.patch
I would like to use {{release:update-versions}} to explicitly update the
versions of my multiproject. Unfortunetly the release plugin converts the
given developmentVersion to a SNAPSHOT version. It happens in
{{MapVersionPhase.getNextVersion()}}.
I would expect the plugin to leave the given developmentVersion property as
it is, because the prompt version will not be converted. Here is my command
line:
{{mvn release:update-versions -DautoVersionSubmodules=true
-DdevelopmentVersion=2.0.1 -DpushChanges=false}}
I made a patch and attached it to the issue.
--
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-674) release plugin converts explicit version to snapshot
[
https://jira.codehaus.org/browse/MRELEASE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-674.
---
Resolution: Fixed
Sounds to me you should use {{updateWorkingCopyVersions=false}}. MRELEASE-760
has been fixed, so this should work with the next release.
release plugin converts explicit version to snapshot
-
Key: MRELEASE-674
URL: https://jira.codehaus.org/browse/MRELEASE-674
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: update-versions
Affects Versions: 2.1
Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
Java version: 1.6.0_23, vendor: Sun Microsystems Inc.
Java home: i:\tools\jdk\1.6.0_23\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: windows xp, version: 5.1, arch: x86, family: windows
Reporter: Bernd Mau
Assignee: Robert Scholte
Fix For: 2.4
Attachments: MapVersionPhase.patch
I would like to use {{release:update-versions}} to explicitly update the
versions of my multiproject. Unfortunetly the release plugin converts the
given developmentVersion to a SNAPSHOT version. It happens in
{{MapVersionPhase.getNextVersion()}}.
I would expect the plugin to leave the given developmentVersion property as
it is, because the prompt version will not be converted. Here is my command
line:
{{mvn release:update-versions -DautoVersionSubmodules=true
-DdevelopmentVersion=2.0.1 -DpushChanges=false}}
I made a patch and attached it to the issue.
--
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-674) release plugin converts explicit version to snapshot
[
https://jira.codehaus.org/browse/MRELEASE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-674.
---
Resolution: Won't Fix
Fix Version/s: (was: 2.4)
Marking this as {{won't fix}}, since there's another parameter which should be
used.
release plugin converts explicit version to snapshot
-
Key: MRELEASE-674
URL: https://jira.codehaus.org/browse/MRELEASE-674
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: update-versions
Affects Versions: 2.1
Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
Java version: 1.6.0_23, vendor: Sun Microsystems Inc.
Java home: i:\tools\jdk\1.6.0_23\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: windows xp, version: 5.1, arch: x86, family: windows
Reporter: Bernd Mau
Assignee: Robert Scholte
Attachments: MapVersionPhase.patch
I would like to use {{release:update-versions}} to explicitly update the
versions of my multiproject. Unfortunetly the release plugin converts the
given developmentVersion to a SNAPSHOT version. It happens in
{{MapVersionPhase.getNextVersion()}}.
I would expect the plugin to leave the given developmentVersion property as
it is, because the prompt version will not be converted. Here is my command
line:
{{mvn release:update-versions -DautoVersionSubmodules=true
-DdevelopmentVersion=2.0.1 -DpushChanges=false}}
I made a patch and attached it to the issue.
--
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-525) Update-versions does not work in batch mode
[
https://jira.codehaus.org/browse/MRELEASE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300149#comment-300149
]
Robert Scholte commented on MRELEASE-525:
-
Could this be a duplicate of MRELEASE-760?
Update-versions does not work in batch mode
---
Key: MRELEASE-525
URL: https://jira.codehaus.org/browse/MRELEASE-525
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: update-versions
Affects Versions: 2.0
Environment: Maven 2.2.1
Reporter: Damien Coraboeuf
When I run the {{release:update-versions}} goal in batch mode, it performs
the transformation and just cleans the things up...
Command which is executed:
{{mvn -B release:update-versions -DautoVersionSubmodules=true
-DdevelopmentVersion=0.4.0}}
The output looks like:
{noformat}
[INFO] Transforming 'ModuleA'...
[INFO] Transforming 'ModuleB'...
[INFO] Cleaning up after release...
{noformat}
If I run the command in interactive mode, everything goes fine:
{{mvn -B release:update-versions -DautoVersionSubmodules=true}}
It asks the version on the prompt and updates the pom files accordingly.
Any idea?
--
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] (MENFORCER-132) Add missing rules to standard rules page and reorder them
Robert Scholte created MENFORCER-132:
Summary: Add missing rules to standard rules page and reorder them
Key: MENFORCER-132
URL: https://jira.codehaus.org/browse/MENFORCER-132
Project: Maven 2.x Enforcer Plugin
Issue Type: Task
Components: Standard Rules
Affects Versions: 1.1
Reporter: Robert Scholte
Priority: Minor
The {{RequireNoRepositories}} is quite an important rule, which is not listed
on the [Standard
Rules|http://maven.apache.org/enforcer/enforcer-rules/index.html]-page, just
like the {{RequireActiveProfile}} rule.
While we're here, let's apply some order to these rules.
--
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] (MENFORCER-132) Add missing rules to standard rules page and reorder them
[
https://jira.codehaus.org/browse/MENFORCER-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MENFORCER-132.
Resolution: Fixed
Fix Version/s: 1.2
Assignee: Robert Scholte
Fixed in [r1345310|http://svn.apache.org/viewvc?rev=1345310view=rev]
Add missing rules to standard rules page and reorder them
-
Key: MENFORCER-132
URL: https://jira.codehaus.org/browse/MENFORCER-132
Project: Maven 2.x Enforcer Plugin
Issue Type: Task
Components: Standard Rules
Affects Versions: 1.1
Reporter: Robert Scholte
Assignee: Robert Scholte
Priority: Minor
Fix For: 1.2
The {{RequireNoRepositories}} is quite an important rule, which is not listed
on the [Standard
Rules|http://maven.apache.org/enforcer/enforcer-rules/index.html]-page, just
like the {{RequireActiveProfile}} rule.
While we're here, let's apply some order to these rules.
--
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-635) perform does not honor updateWorkingCopiesVersion setting
[ https://jira.codehaus.org/browse/MRELEASE-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MRELEASE-635: Component/s: (was: perform) prepare perform does not honor updateWorkingCopiesVersion setting - Key: MRELEASE-635 URL: https://jira.codehaus.org/browse/MRELEASE-635 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.1 Reporter: Scott Carey release:perform modifies the working copies version when configured not to. This was a tag directly from trunk. configuration autoVersionSubmodulestrue/autoVersionSubmodules remoteTaggingfalse/remoteTagging suppressCommitBeforeTagtrue/suppressCommitBeforeTag suppressCommitBeforeBranchtrue/suppressCommitBeforeBranch updateBranchVersionstrue/updateBranchVersions updateWorkingCopyVersionsfalse/updateWorkingCopyVersions /configuration Happens in both dryRun mode and normal. After a non-dryRun pom.xml.releaseBackup files are left behind as well. The desired behavior is to leave the working copy alone and only modify the tag. Currently, with suppressCommitBeforeTag true, this is possible by reverting the local changes left behind by running release:perform. -- 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-635) perform does not honor updateWorkingCopiesVersion setting
[ https://jira.codehaus.org/browse/MRELEASE-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-635. --- Resolution: Duplicate Assignee: Robert Scholte Superseded by MRELEASE-760, which will be part of the next release. perform does not honor updateWorkingCopiesVersion setting - Key: MRELEASE-635 URL: https://jira.codehaus.org/browse/MRELEASE-635 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.1 Reporter: Scott Carey Assignee: Robert Scholte release:perform modifies the working copies version when configured not to. This was a tag directly from trunk. configuration autoVersionSubmodulestrue/autoVersionSubmodules remoteTaggingfalse/remoteTagging suppressCommitBeforeTagtrue/suppressCommitBeforeTag suppressCommitBeforeBranchtrue/suppressCommitBeforeBranch updateBranchVersionstrue/updateBranchVersions updateWorkingCopyVersionsfalse/updateWorkingCopyVersions /configuration Happens in both dryRun mode and normal. After a non-dryRun pom.xml.releaseBackup files are left behind as well. The desired behavior is to leave the working copy alone and only modify the tag. Currently, with suppressCommitBeforeTag true, this is possible by reverting the local changes left behind by running release:perform. -- 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-616) release:rollback does not honor -DcommitByProject
[
https://jira.codehaus.org/browse/MRELEASE-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-616.
---
Resolution: Fixed
Fix Version/s: 2.4
Assignee: Robert Scholte
Fixed in [r1345488| http://svn.apache.org/viewvc?rev=1345488view=rev]
{{commitByProject}} is now stored in the {{release.properties}}, so the
{{rollback}}-goal should be able to pick it up.
release:rollback does not honor -DcommitByProject
-
Key: MRELEASE-616
URL: https://jira.codehaus.org/browse/MRELEASE-616
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: rollback
Affects Versions: 2.1
Reporter: Steven Schlansker
Assignee: Robert Scholte
Fix For: 2.4
MRELEASE-168 added a commitByProject flag to release:prepare for situations
where you have a project layout
proj/
mod1/
mod2/
where proj, mod1, mod2 are all different SCM repositories.
Effectively, instead of doing
commit proj/pom.xml proj/mod1/pom.xml proj/mod2/pom.xml
it will run
commit proj/pom.xml
commit proj/mod1/pom.xml
commit proj/mod2/pom.xml
This works great, but release:rollback doesn't know about this and still
tries to commit them all in one go, which fails if they are different source
repositories.
--
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-726) mvn release:prepare-with-pom not honouring the commitByProject parameter.
[
https://jira.codehaus.org/browse/MRELEASE-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300227#comment-300227
]
Robert Scholte commented on MRELEASE-726:
-
Is this still happening with version 2.3.1?
A quick scan over the code tells me that a {{pom.xml}} and optional
{{release-pom.xml}} should be committed at once when {{commitByProject}} is
activated.
I can't see during which release-phase this commit is happening, so could you
add more (debug)-logging?
mvn release:prepare-with-pom not honouring the commitByProject parameter.
-
Key: MRELEASE-726
URL: https://jira.codehaus.org/browse/MRELEASE-726
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: Git, prepare-with-pom
Affects Versions: 2.2.2
Environment: Linux 64bit (Ubuntu).
Reporter: Dave Fennell
Priority: Blocker
Using this in my pom file:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.2.2/version
configuration
goalsdeploy/goals
pushChangesfalse/pushChanges
localCheckouttrue/localCheckout
commitByProjecttrue/commitByProject
/configuration
/plugin
{code}
Running this command:
{{mvn release:prepare}}
Correctly goes into each directory to make changes, e.g.
{noformat}
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel git add --
pom.xml
[INFO] Working directory: /usr/local/src/whitelabel
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel git status
[INFO] Working directory: /usr/local/src/whitelabel
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel git commit
--verbose -F /tmp/maven-scm-561169862.commit pom.xml
[INFO] Working directory: /usr/local/src/whitelabel
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation git
add -- pom.xml
[INFO] Working directory: /usr/local/src/whitelabel/foundation
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation git
status
[INFO] Working directory: /usr/local/src/whitelabel/foundation
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation git
commit --verbose -F /tmp/maven-scm-2018482909.commit pom.xml
{noformat}
etc ...
However running this command:
{{mvn release:prepare-with-pom}}
So that I can generate a release-pom.xml file errors because it attempts to
do all the checkins on one line:
{noformat}
[INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel git add --
release-pom.xml foundation/release-pom.xml module/release-pom.xml
module/advertising/release-pom.xml module/buttonconfig/release-pom.xml
module/core/release-pom.xml module/film/release-pom.xml
module/profile/release-pom.xml module/proxy/release-pom.xml
module/rental/release-pom.xml module/service/release-pom.xml
module/smartcard/release-pom.xml module/telephony/release-pom.xml
module/terminalui/release-pom.xml module/tv/release-pom.xml
module/upsell/release-pom.xml module/urlconfig/release-pom.xml
mule/release-pom.xml mule/advertising/release-pom.xml
mule/button-config/release-pom.xml mule/film/release-pom.xml
mule/hospediacard/release-pom.xml mule/location/release-pom.xml
mule/profile/release-pom.xml mule/proxy/release-pom.xml
mule/rental/release-pom.xml mule/service/release-pom.xml
mule/smartcard/release-pom.xml mule/startup/release-pom.xml
mule/terminaluimenu/release-pom.xml mule/tv/release-pom.xml
mule/upsell/release-pom.xml mule/urlconfig/release-pom.xml
{noformat}
This doesn't work for my setup because each directory is a git submodule so
must be run separately, it looks to me like it's simply ignoring the
{{commitByProject}} setting, but the docs
(http://maven.apache.org/plugins/maven-release-plugin/prepare-with-pom-mojo.html)
list it as being a supported property since {{2.0-beta5}}. I've marked this
as a blocker because I wanted to use the release-pom.xml and I have no way to
generate them now (since the {{-DgenerateReleasePoms}} option on the
{{release:prepare}} goal seems to have been deprecated).
--
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-339) Exception AuthenticationException during release:prepare phase when committing versioned POMs
[ https://jira.codehaus.org/browse/MRELEASE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-339. --- Resolution: Won't Fix Assignee: Robert Scholte Like you discovered yourself: it doesn't seem to be a maven-release-plugin bug. There doesn't seem to exist a newer version (http://search.maven.org/#search%7Cga%7C1%7Ccvsclient). If there was a newer version, it should be fixed in the [SCM Project#cvs|https://jira.codehaus.org/browse/SCM/component/11190]. So there's nothing we can do here. Exception AuthenticationException during release:prepare phase when committing versioned POMs - Key: MRELEASE-339 URL: https://jira.codehaus.org/browse/MRELEASE-339 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Environment: Windows XP CVS hosted on linux fedora maven 2.0.8 Reporter: Gervais Mickaël Assignee: Robert Scholte Priority: Blocker I try to use release:prepare plugin. 1st phase: changing pom version is ok 2nd phase: building and deploying new version is ok 3rd phase: commiting POMs fails with this exception: org.netbeans.lib.cvsclient.connection.AuthenticationException: Authentication failed. Response from server was: error 0 :/c. at org.netbeans.lib.cvsclient.connection.PServerConnection.openConnection(PServerConnection.java:238) at org.netbeans.lib.cvsclient.connection.PServerConnection.open(PServerConnection.java:326) at org.apache.maven.scm.provider.cvslib.cvsjava.util.CvsConnection.connect(CvsConnection.java:164) at org.apache.maven.scm.provider.cvslib.cvsjava.util.CvsConnection.processCommand(CvsConnection.java:475) I didn't find cvsclient-20060125.jar (which is a netbean API) sources with are used in the maven plugin. So I've download the lastest from netbean web site, I've packaged the new version and replace the cvsclient-20060125.jar with the new one. I've relaunched release:prepare and everything is ok... Is this a bug? Did I do something wrong? 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] (MRELEASE-352) Record Maven version and java version used during release.
[
https://jira.codehaus.org/browse/MRELEASE-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300232#comment-300232
]
Robert Scholte commented on MRELEASE-352:
-
Is it a problem if the {{release:perform}} is executed with a different Maven
version, Java version or OS then {{release:prepare}}? I think it is much more
important to know with which environment the final/release version was built.
Recently we've been able to add the Maven-version to the Manifest file.
I'd prefer to store this kind of information in that file, so that you should
be able rebuild a project somewhere in the future with the same settings.
Record Maven version and java version used during release.
--
Key: MRELEASE-352
URL: https://jira.codehaus.org/browse/MRELEASE-352
Project: Maven 2.x Release Plugin
Issue Type: New Feature
Components: perform
Reporter: Paul Gier
The release plugin should be able to record the version of Maven and the
version of the JDK that were used when the release was done.
For example, the prepare phase could write a file called
environment-settings.xml that contains the version of Maven and of Java that
were used during the prepare step. This file could look something like this:
{code:xml}
environment
maven
version2.0.8/version
/maven
java
version1.4.2_15/version
vendorsun/vendor
/java
os
namewindows/name
...
/os
/environment
{code}
The perform part of the release would then make sure that these settings
match when the project is re-built and deployed. There could also be another
goal in the release plugin, like check-environment that would check that
the environment settings match. That goal could be used when trying to
rebuild an old release.
--
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-714) Prevent snapshot version bumping does not seem to work
[
https://jira.codehaus.org/browse/MRELEASE-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-714:
Description:
I want to use the release plugin within our company, and I want to create a
tags for multi-module projects, such as the following example:
{noformat}
tags/parent-1.0.0
- child1 (1.0.0)
- child2 (1.0.0)
{noformat}
When I do {{release:prepare}}, snapshots with an increased version are
created and committed for every parent/child module, so:
{{parent-1.0.0-SNAPSHOT, child1-1.0.0-SNAPSHOT, child2-1.0.0-SNAPSHOT}}
becomes:
{{parent-1.0.1-SNAPSHOT, child1-1.0.1-SNAPSHOT, child2-1.0.1-SNAPSHOT}}
However, when I create a release I don't want to automatically create snapshot
versions for every child module, so I'd like to bump the version number to
1.0.1-SNAPSHOT manually. Sometimes we create a new release in which for
instance 3 of the 10 child modules have actually been updated, so we want to
just set those 3 version numbers to an increased SNAPSHOT version. I tried
accomplishing this by setting the following properties to false:
{code:xml}
updateWorkingCopyVersionsfalse/updateWorkingCopyVersions
updateDependenciesfalse/updateDependencies
{code}
However, whatever I try, it doesn't work. The 1.0.0-SNAPSHOT versions keep
getting bumped to 1.0.1-SNAPSHOT.
Furthermore, a little off topic, but is it possible to have version numbers
created for sub modules? E.g.:
{noformat}
tags/parent-1.0.0
- child1-1.0.0
- child2-1.0.0)
{noformat}
was:
I want to use the release plugin within our company, and I want to create a
tags for multi-module projects, such as the following example:
tags/parent-1.0.0
- child1 (1.0.0)
- child2 (1.0.0)
When I do release: prepare, snapshots with an increased version are created
and committed for every parent/child module, so:
parent-1.0.0-SNAPSHOT, child1-1.0.0-SNAPSHOT, child2-1.0.0-SNAPSHOT
becomes:
parent-1.0.1-SNAPSHOT, child1-1.0.1-SNAPSHOT, child2-1.0.1-SNAPSHOT
However, when I create a release I don't want to automatically create snapshot
versions for every child module, so I'd like to bump the version number to
1.0.1-SNAPSHOT manually. Sometimes we create a new release in which for
instance 3 of the 10 child modules have actually been updated, so we want to
just set those 3 version numbers to an increased SNAPSHOT version. I tried
accomplishing this by setting the following properties to false:
updateWorkingCopyVersionsfalse/updateWorkingCopyVersions
updateDependenciesfalse/updateDependencies
However, whatever I try, it doesn't work. The 1.0.0-SNAPSHOT versions keep
getting bumped to 1.0.1-SNAPSHOT.
Furthermore, a little off topic, but is it possible to have version numbers
created for sub modules? E.g.:
tags/parent-1.0.0
- child1-1.0.0
- child2-1.0.0)
Prevent snapshot version bumping does not seem to work
--
Key: MRELEASE-714
URL: https://jira.codehaus.org/browse/MRELEASE-714
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Paul S
I want to use the release plugin within our company, and I want to create a
tags for multi-module projects, such as the following example:
{noformat}
tags/parent-1.0.0
- child1 (1.0.0)
- child2 (1.0.0)
{noformat}
When I do {{release:prepare}}, snapshots with an increased version are
created and committed for every parent/child module, so:
{{parent-1.0.0-SNAPSHOT, child1-1.0.0-SNAPSHOT, child2-1.0.0-SNAPSHOT}}
becomes:
{{parent-1.0.1-SNAPSHOT, child1-1.0.1-SNAPSHOT, child2-1.0.1-SNAPSHOT}}
However, when I create a release I don't want to automatically create
snapshot versions for every child module, so I'd like to bump the version
number to 1.0.1-SNAPSHOT manually. Sometimes we create a new release in which
for instance 3 of the 10 child modules have actually been updated, so we want
to just set those 3 version numbers to an increased SNAPSHOT version. I tried
accomplishing this by setting the following properties to false:
{code:xml}
updateWorkingCopyVersionsfalse/updateWorkingCopyVersions
updateDependenciesfalse/updateDependencies
{code}
However, whatever I try, it doesn't work. The 1.0.0-SNAPSHOT versions keep
getting bumped to 1.0.1-SNAPSHOT.
Furthermore, a little off topic, but is it possible to have version numbers
created for sub modules? E.g.:
{noformat}
tags/parent-1.0.0
- child1-1.0.0
- child2-1.0.0)
{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] (MRELEASE-714) Prevent snapshot version bumping does not seem to work
[
https://jira.codehaus.org/browse/MRELEASE-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300233#comment-300233
]
Robert Scholte commented on MRELEASE-714:
-
Looks related to MRELEASE-760 and should be fixed by now. Can you confirm this?
About your off topic issue: Looks related to MRELEASE-241.
If child1 and child2 are subfolders of parent then you don't want to have
version-numbers in the module names.
You must be able to check out the code by tag and run {{mvn install}}.
To find child1-1.0.0 you always have to find tags/parent-1.0.0 first, so the
information will be redundant.
Prevent snapshot version bumping does not seem to work
--
Key: MRELEASE-714
URL: https://jira.codehaus.org/browse/MRELEASE-714
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Paul S
I want to use the release plugin within our company, and I want to create a
tags for multi-module projects, such as the following example:
{noformat}
tags/parent-1.0.0
- child1 (1.0.0)
- child2 (1.0.0)
{noformat}
When I do {{release:prepare}}, snapshots with an increased version are
created and committed for every parent/child module, so:
{{parent-1.0.0-SNAPSHOT, child1-1.0.0-SNAPSHOT, child2-1.0.0-SNAPSHOT}}
becomes:
{{parent-1.0.1-SNAPSHOT, child1-1.0.1-SNAPSHOT, child2-1.0.1-SNAPSHOT}}
However, when I create a release I don't want to automatically create
snapshot versions for every child module, so I'd like to bump the version
number to 1.0.1-SNAPSHOT manually. Sometimes we create a new release in which
for instance 3 of the 10 child modules have actually been updated, so we want
to just set those 3 version numbers to an increased SNAPSHOT version. I tried
accomplishing this by setting the following properties to false:
{code:xml}
updateWorkingCopyVersionsfalse/updateWorkingCopyVersions
updateDependenciesfalse/updateDependencies
{code}
However, whatever I try, it doesn't work. The 1.0.0-SNAPSHOT versions keep
getting bumped to 1.0.1-SNAPSHOT.
Furthermore, a little off topic, but is it possible to have version numbers
created for sub modules? E.g.:
{noformat}
tags/parent-1.0.0
- child1-1.0.0
- child2-1.0.0)
{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] (MRELEASE-482) Wrong URL for commiting to SVN
[
https://jira.codehaus.org/browse/MRELEASE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-482.
---
Resolution: Incomplete
Assignee: Robert Scholte
No feedback from user, closing it.
Wrong URL for commiting to SVN
--
Key: MRELEASE-482
URL: https://jira.codehaus.org/browse/MRELEASE-482
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: branch
Affects Versions: 2.0-beta-8, 2.0-beta-9
Environment: All
Reporter: Markus Heimhuber
Assignee: Robert Scholte
Priority: Critical
Command:
---
{noformat}
set PROJECT_NAME=fytools
set RELEASE_VERSION=1.1
set NEXT_VERSION=1.2
set URL=http://svn.office.factority.de/factority
set URL_BRANCHES=%URL%/BRANCHES
set DRY=false
mvn -U --batch-mode release:branch -Dusername=%USERNAME%
-Dpassword=%PASSWORD% \
-DtagBase=%URL_BRANCHES% -DautoVersionSubmodules=true
-DupdateBranchVersions=true \
-DupdateWorkingCopyVersions=false
-DbranchName=%PROJECT_NAME%-%RELEASE_VERSION%.1-SNAPSHOT \
-DdevelopmentVersion=%RELEASE_VERSION%.1-SNAPSHOT -DdryRun=%DRY%
{noformat}
Symptom:
---
The resulting POM contains the expected SVM link:
{noformat}
http://svn.office.factority.de/factority/BRANCHES/fytools-1.1.1-SNAPSHOT
{noformat}
The execution log contains the following:
{noformat}
[INFO] Executing: cmd.exe /X /C svn --username msheimhu --password *
--non-interactive copy
--file C:\Users\X\AppData\Local\Temp\maven-scm-439769046.commit .
http://svn.office.factority.de/factority/fytools/branches/fytools-1.1.1-SNAPSHOT;
{noformat}
The execution log indicates, that Maven tries to commit to the following link:
{noformat}
http://svn.office.factority.de/factority/fytools/branches/fytools-1.1.1-SNAPSHOT
{noformat}
This fails with the following error message:
{noformat}
[INFO] Working directory: C:\Users\msheimhu\workspace\fytools
org.apache.maven.shared.release.scm.ReleaseScmCommandException: Unable to
branch SCM
Provider message:
The svn branch command failed.
Command output:
svn: Commit failed (details follow):
svn: '/factority/fytools/branches' path not found
{noformat}
Expected behaviour:
---
The commit should use the URL from the POM, which is the correct one:
{noformat}
http://svn.office.factority.de/factority/BRANCHES/fytools-1.1.1-SNAPSHOT
{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] (MRELEASE-309) Perform goal fails if -f option is used to define non-default path to pom file
[ https://jira.codehaus.org/browse/MRELEASE-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-309. --- Resolution: Duplicate Assignee: Robert Scholte Superseded by MRELEASE-757 Perform goal fails if -f option is used to define non-default path to pom file --- Key: MRELEASE-309 URL: https://jira.codehaus.org/browse/MRELEASE-309 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.0-beta-7 Reporter: Brian Jackson Assignee: Robert Scholte Attachments: pomFileName.patch, pomFileNameWithTestCase.patch The RunPerformGoalsPhase hardcodes the pom name as pom.xml instead of using releaseDescriptor.getPomFileName(). This causes the perform goal to fail if the filename is different or the plugin is run from a different directory. -- 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-625) mvn release:perform Problem
[
https://jira.codehaus.org/browse/MRELEASE-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-625.
---
Resolution: Not A Bug
Assignee: Robert Scholte
It looks to me your SCM connection was misconfigured. The project was tagged
one level too high, since I see {{source}} and {{portal-all}}. When checking
out by tag it is missing the pom, so the release-plugin can't run Maven.
mvn release:perform Problem
---
Key: MRELEASE-625
URL: https://jira.codehaus.org/browse/MRELEASE-625
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.1
Environment: Linux Ubuntu 10.4
java version 1.6.0_21
Maven 2.2.1
Reporter: Vinicius de Paula
Assignee: Robert Scholte
Attachments: maven.log
Hi folks,
I have a problem when i'm trying to run the Maven task: mvn -X release:perform
My pom.xml plugin definition:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.1/version
configuration
remoteTaggingtrue/remoteTagging
arguments-Dmaven.test.skip/arguments
tagBasehttps://svn/repo/portal/tags//tagBase
/configuration
/plugin
{code}
Debug stacktrace:
Checkout from an SCM URL was done successfully.
In deploy goal the error ocurr. If i execute only mvn deploy, its done
successfully.
{noformat}
[WARNING] Maven will be executed in interactive mode, but no input stream has
been configured for this MavenInvoker instance.
[INFO] + Error stacktraces are turned on.
[INFO] Apache Maven 2.2.1 (rdebian-1)
[INFO] Java version: 1.6.0_21
[INFO] Java home: /opt/java/jdk1.6.0_21/jre
[INFO] Default locale: en_US, platform encoding: UTF-8
[INFO] OS name: linux version: 2.6.32-26-generic arch: i386 Family:
unix
[INFO] [DEBUG] Building Maven user-level plugin registry from:
'/home/vinidog/.m2/plugin-registry.xml'
[INFO] [DEBUG] Building Maven global-level plugin registry from:
'/usr/share/maven2/conf/plugin-registry.xml'
[INFO] [INFO] Scanning for projects...
[INFO] [DEBUG] Wagons could not be registered as the extension container was
never created
[INFO] [INFO]
[INFO] [INFO] Building Maven Default Project
[INFO] [INFO]task-segment: [deploy]
[INFO] [INFO]
[INFO] [DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins:pom:12 for project:
null:maven-resources-plugin:maven-plugin:2.3 from the repository.
[INFO] [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:9 for
project: org.apache.maven.plugins:maven-plugins:pom:12 from the repository.
[INFO] [DEBUG] Retrieving parent-POM: org.apache:apache:pom:4 for project:
org.apache.maven:maven-parent:pom:9 from the repository.
[INFO] [DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins:pom:8 for project:
null:maven-compiler-plugin:maven-plugin:2.0.2 from the repository.
[INFO] [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:5 for
project: org.apache.maven.plugins:maven-plugins:pom:8 from the repository.
[INFO] [DEBUG] Retrieving parent-POM: org.apache:apache:pom:3 for project:
org.apache.maven:maven-parent:pom:5 from the repository.
[INFO] [DEBUG] Retrieving parent-POM:
org.apache.maven.surefire:surefire:pom:2.4.3 for project:
org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:null from the
repository.
[INFO] [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:7 for
project: org.apache.maven.surefire:surefire:pom:2.4.3 from the repository.
[INFO] [DEBUG] Adding managed dependencies for
org.apache.maven.plugins:maven-surefire-plugin
[INFO] [DEBUG] org.apache.maven.surefire:surefire-api:jar:2.4.3
[INFO] [DEBUG] org.apache.maven.surefire:surefire-booter:jar:2.4.3
[INFO] [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.1
[INFO] [DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins:pom:10 for project:
null:maven-jar-plugin:maven-plugin:2.2 from the repository.
[INFO] [DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins:pom:13 for project:
null:maven-install-plugin:maven-plugin:2.3 from the repository.
[INFO] [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:11
for project: org.apache.maven.plugins:maven-plugins:pom:13 from the
repository.
[INFO] [DEBUG] Retrieving parent-POM: org.apache:apache:pom:5 for project:
org.apache.maven:maven-parent:pom:11 from the repository.
[INFO] [DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins:pom:11 for project:
null:maven-deploy-plugin:maven-plugin:2.4 from the repository.
[INFO] [DEBUG] Retrieving parent-POM:
[jira] (MRELEASE-643) it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2
[ https://jira.codehaus.org/browse/MRELEASE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-643. --- Resolution: Incomplete Assignee: Robert Scholte No feedback from user, closing it. it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2 Key: MRELEASE-643 URL: https://jira.codehaus.org/browse/MRELEASE-643 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.1 Environment: Win 7 64-bit Maven 3.0.2 Reporter: shane mills Assignee: Robert Scholte We use Maven as project management tool. For building releases we use maven-release-plugin. Up until a few days ago we used Maven 2.2.1 but unfortunately we recognized that for some reason when triggering mvn release:prepare on a project with local modifications it would just prepare the release without saying anything about it. We actually just recognized this issue a few days ago so I started to track down the problem with no result but the fact that with maven 3 it terminates just as expected. So instead of tracking down the maven 2.2.1 issue i started to check on maven 3 and if we could use it instead of maven 2.2.1. Actually everything works just fine except of the site-plugin. I found out that with maven 3.x you should use the site-plugin 3.x and so i tried to bend dependencies so that the release-plugin uses the site-plugin 3.0-beta-3 instead of site-plugin 2.0.1, but it just wont do so. When triggering mvn site:site on the command line it works just fine, but when triggering mvn release:prepare and afterwards mvn release:perform it still uses the site-plugin 2.0.1 not as expected maven-site-plugin 3.0-beta-3. I am using maven 3.0.2 with maven-release-plugin 2.0.1 We are looking forward to switching to maven 3.x but at first we need to be sure everything works at least as fine as with maven 2.2.1 :) -- 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-456) Resolving version during release:prepare of main
[ https://jira.codehaus.org/browse/MRELEASE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-456. --- Resolution: Incomplete Assignee: Robert Scholte No feedback from user, closing it. Resolving version during release:prepare of main Key: MRELEASE-456 URL: https://jira.codehaus.org/browse/MRELEASE-456 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform, prepare Affects Versions: 2.0-beta-8 Environment: Windows Vista(main release), Unix(other projects' build), Nexus Repository Manager,Maven2.1.0, Maven-release-plugin2.0-beta-8 Reporter: Puneet Sahani Assignee: Robert Scholte Attachments: error.txt Hi, we have a main project(of type pom) containing DependencyMgmt section which lists all the projects and a version property pointing to SNAPSHOT by default and changed to a version range with the activation of a profile. All other projects have a concrete versioned 'main' as there parent. But from my local PC(Windows Vista), if i run release:prepare of the main project, while deploying the pom to Nexus, it resolves the tag to the SNAPSHOT dependency. Hence build during the patch/release is failing during dependency resolution as it tries to resolve SNAPSHOT dependency instead of resolving via the Version-Range. I switched back to Maven2.0.9 and it works fine. -- 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-200) Artifacts are uploaded to wrong directory
[ https://jira.codehaus.org/browse/MRELEASE-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300331#comment-300331 ] Robert Scholte commented on MRELEASE-200: - I agree with Emmanuel, I don't think it's a maven-release-plugin issue, but it's more likely a [wagon|http://maven.apache.org/wagon]-issue, which is responsible for the movements of files. Without logs it's hard too see which causes this problem. Artifacts are uploaded to wrong directory - Key: MRELEASE-200 URL: https://jira.codehaus.org/browse/MRELEASE-200 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Environment: The maven repository is running Red Hat Linux Enterprise Server. The clients are PCs running Windows XP. Reporter: Chris Baumgartner Priority: Minor When doing a release:perform, the artifacts are occassionally uploaded to the wrong directory. We are using scp from the upload. Instead of uploading to the path of /maven-repository, the files are being uploaded to ~/om/maven-repository. For some reason it is creating a subdirectory called om in the user's home directory and uploading the artifacts there. It doesn't happen all the time, but it does seem to be consitently putting them there when it does fail. I can work around this by manually moving the files, but it is very annoying. -- 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-298) -DupdateDependencies flag is not honored in non-interactive mode
[
https://jira.codehaus.org/browse/MRELEASE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-298:
Description:
Doing {{mvn release:prepare}} In non-interactive mode always fails if my
release depends on SNAPSHOTS. I would like it to automatically resolveSnapshots
as although I said yes, However setting {{-DupdateDependencies}} doesn't
help.
{noformat}
org.apache.maven.BuildFailureException: Can't release project due to non
released dependencies :
com.BLAH.test:test-dummy1:jar:1.0.0-SNAPSHOT:compile
in project '' (com.BLAH.test:test-dummy2:jar:1.0.0-SNAPSHOT)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
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.MojoFailureException: Can't release project
due to non released dependencies :
com.BLAH.test:test-dummy1:jar:1.0.0-SNAPSHOT:compile
in project '' (com.ml.elt.era.test:test-dummy2:jar:1.0.0-SNAPSHOT)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:144)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
... 16 more
{noformat}
was:
Doing mvn release:prepare In non-interactive mode always fails if my release
depends on SNAPSHOTS. I would like it to automatically resolveSnapshots as
although I said yes, However settig -DupdateDependencies doesn't help
org.apache.maven.BuildFailureException: Can't release project due to non
released dependencies :
com.BLAH.test:test-dummy1:jar:1.0.0-SNAPSHOT:compile
in project '' (com.BLAH.test:test-dummy2:jar:1.0.0-SNAPSHOT)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
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.MojoFailureException: Can't release project
due to non released dependencies :
com.BLAH.test:test-dummy1:jar:1.0.0-SNAPSHOT:compile
in project ''
[jira] (MRELEASE-767) releasing flat multi-module projects using git
[ https://jira.codehaus.org/browse/MRELEASE-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MRELEASE-767: --- Assignee: Mark Struberg I've talked with Mark about this. He'll have a look at it once he has some more time. releasing flat multi-module projects using git -- Key: MRELEASE-767 URL: https://jira.codehaus.org/browse/MRELEASE-767 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.3.1 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800) Maven home: /usr/share/maven Java version: 1.6.0_31, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x, version: 10.7.4, arch: x86_64, family: mac Reporter: Jeremy Norris Assignee: Mark Struberg When releasing a project as follows: ./parent/pom.xml ./module-a/pom.xml ./module-b/pom.xml From the parent directory, with an scm config in the parent pom.xml (only) as follows: scm connectionscm:git:ssh://github.com/repox.git/connection developerConnectionscm:git:ssh://github.com/repox.git/developerConnection tagmaster/tag urlhttps://github.com/view/repox.git/url /scm In org/apache/maven/shared/release/util/ReleaseUtils.java:182 it does this indiscriminately: url = realignScmUrl( parentLevels, url ); This will trim the repo url from 'ssh://github.com/repox.git' - 'ssh://github.com', which will cause a failure when pushing the tag. This type of realignment is not appropriate when using a git scm type. -- 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-643) it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2
[ https://jira.codehaus.org/browse/MRELEASE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reopened MRELEASE-643: - it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2 Key: MRELEASE-643 URL: https://jira.codehaus.org/browse/MRELEASE-643 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.1 Environment: Win 7 64-bit Maven 3.0.2 Reporter: shane mills Assignee: Robert Scholte We use Maven as project management tool. For building releases we use maven-release-plugin. Up until a few days ago we used Maven 2.2.1 but unfortunately we recognized that for some reason when triggering mvn release:prepare on a project with local modifications it would just prepare the release without saying anything about it. We actually just recognized this issue a few days ago so I started to track down the problem with no result but the fact that with maven 3 it terminates just as expected. So instead of tracking down the maven 2.2.1 issue i started to check on maven 3 and if we could use it instead of maven 2.2.1. Actually everything works just fine except of the site-plugin. I found out that with maven 3.x you should use the site-plugin 3.x and so i tried to bend dependencies so that the release-plugin uses the site-plugin 3.0-beta-3 instead of site-plugin 2.0.1, but it just wont do so. When triggering mvn site:site on the command line it works just fine, but when triggering mvn release:prepare and afterwards mvn release:perform it still uses the site-plugin 2.0.1 not as expected maven-site-plugin 3.0-beta-3. I am using maven 3.0.2 with maven-release-plugin 2.0.1 We are looking forward to switching to maven 3.x but at first we need to be sure everything works at least as fine as with maven 2.2.1 :) -- 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-643) it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2
[
https://jira.codehaus.org/browse/MRELEASE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-643.
---
Resolution: Not A Bug
This is not a ((maven-release-plugin}} bug, but a Maven-bug. Up to version
{{3.0.3}} the {{super-pom.xml}} contained a 2.x version of the
{{maven-site-plugin}}, which is incompatible with Maven3. This has been fix for
Maven-3.0.4
But... you shouldn't rely on the versions in the {{super-pom}}, because they
can be upgraded with every new release of Maven. It's a best practice to
include these plugins in your own pom with a locked version to keep the build
stable for ages.
it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2
Key: MRELEASE-643
URL: https://jira.codehaus.org/browse/MRELEASE-643
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.1
Environment: Win 7 64-bit
Maven 3.0.2
Reporter: shane mills
Assignee: Robert Scholte
We use Maven as project management tool.
For building releases we use maven-release-plugin.
Up until a few days ago we used Maven 2.2.1 but unfortunately we recognized
that for some reason when triggering mvn release:prepare on a project with
local modifications it would just prepare the release without saying anything
about it.
We actually just recognized this issue a few days ago so I started to track
down the problem with no result but the fact that with maven 3 it terminates
just as expected. So instead of tracking down the maven 2.2.1 issue i started
to check on maven 3 and if we could use it instead of maven 2.2.1.
Actually everything works just fine except of the site-plugin. I found out
that with maven 3.x you should use the site-plugin 3.x and so i tried to bend
dependencies so that the release-plugin uses the site-plugin 3.0-beta-3
instead of site-plugin 2.0.1, but it just wont do so.
When triggering mvn site:site on the command line it works just fine, but
when triggering mvn release:prepare and afterwards mvn release:perform it
still uses the site-plugin 2.0.1 not as expected maven-site-plugin 3.0-beta-3.
I am using maven 3.0.2 with maven-release-plugin 2.0.1
We are looking forward to switching to maven 3.x but at first we need to be
sure everything works at least as fine as with maven 2.2.1 :)
--
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-643) it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2
[
https://jira.codehaus.org/browse/MRELEASE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300406#comment-300406
]
Robert Scholte edited comment on MRELEASE-643 at 6/5/12 11:07 AM:
--
This is not a {{maven-release-plugin}} bug, but a Maven-bug. Up to version
{{3.0.3}} the {{super-pom.xml}} contained a 2.x version of the
{{maven-site-plugin}}, which is incompatible with Maven3. This has been fix for
Maven-3.0.4
But... you shouldn't rely on the versions in the {{super-pom}}, because they
can be upgraded with every new release of Maven. It's a best practice to
include these plugins in your own pom with a locked version to keep the build
stable for ages.
was (Author: rfscholte):
This is not a ((maven-release-plugin}} bug, but a Maven-bug. Up to version
{{3.0.3}} the {{super-pom.xml}} contained a 2.x version of the
{{maven-site-plugin}}, which is incompatible with Maven3. This has been fix for
Maven-3.0.4
But... you shouldn't rely on the versions in the {{super-pom}}, because they
can be upgraded with every new release of Maven. It's a best practice to
include these plugins in your own pom with a locked version to keep the build
stable for ages.
it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2
Key: MRELEASE-643
URL: https://jira.codehaus.org/browse/MRELEASE-643
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.1
Environment: Win 7 64-bit
Maven 3.0.2
Reporter: shane mills
Assignee: Robert Scholte
We use Maven as project management tool.
For building releases we use maven-release-plugin.
Up until a few days ago we used Maven 2.2.1 but unfortunately we recognized
that for some reason when triggering mvn release:prepare on a project with
local modifications it would just prepare the release without saying anything
about it.
We actually just recognized this issue a few days ago so I started to track
down the problem with no result but the fact that with maven 3 it terminates
just as expected. So instead of tracking down the maven 2.2.1 issue i started
to check on maven 3 and if we could use it instead of maven 2.2.1.
Actually everything works just fine except of the site-plugin. I found out
that with maven 3.x you should use the site-plugin 3.x and so i tried to bend
dependencies so that the release-plugin uses the site-plugin 3.0-beta-3
instead of site-plugin 2.0.1, but it just wont do so.
When triggering mvn site:site on the command line it works just fine, but
when triggering mvn release:prepare and afterwards mvn release:perform it
still uses the site-plugin 2.0.1 not as expected maven-site-plugin 3.0-beta-3.
I am using maven 3.0.2 with maven-release-plugin 2.0.1
We are looking forward to switching to maven 3.x but at first we need to be
sure everything works at least as fine as with maven 2.2.1 :)
--
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-557) release:prepare does not update the version of a reactor plugin
[
https://jira.codehaus.org/browse/MRELEASE-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-557:
Component/s: (was: perform)
prepare
Description:
For example this pom.
{code:xml}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdexample/groupId
artifactIdexample-parent/artifactId
version0.0.1-SNAPSHOT/version
packagingpom/packaging
build
pluginManagement
plugins
plugin
groupIdexample/groupId
artifactIdexample-plugin/artifactId
version0.0.1-SNAPSHOT/version
/plugin
/plugins
/pluginManagement
/build
modules
moduleexample-plugin/module
/modules
/project
{code:xml}
With {{release:prepare}}, the version of the example-plugin in the build
section stays untouched.
BTW: Is the {{pluginManagement}} totally ignored? I even don't get an error, if
I use SNAPSHOT versions in the {{pluginManagement}} section.
was:
For example this pom.
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdexample/groupId
artifactIdexample-parent/artifactId
version0.0.1-SNAPSHOT/version
packagingpom/packaging
build
pluginManagement
plugins
plugin
groupIdexample/groupId
artifactIdexample-plugin/artifactId
version0.0.1-SNAPSHOT/version
/plugin
/plugins
/pluginManagement
/build
modules
moduleexample-plugin/module
/modules
/project
With release:prepare, the version of the example-plugin in the build section
stays untouched.
BTW: Is the pluginManagement totally ignored? I even don't get an error, if I
use SNAPSHOT versions in the pluginManagement section.
release:prepare does not update the version of a reactor plugin
---
Key: MRELEASE-557
URL: https://jira.codehaus.org/browse/MRELEASE-557
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0
Reporter: Frank Ressel
For example this pom.
{code:xml}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdexample/groupId
artifactIdexample-parent/artifactId
version0.0.1-SNAPSHOT/version
packagingpom/packaging
build
pluginManagement
plugins
plugin
groupIdexample/groupId
artifactIdexample-plugin/artifactId
version0.0.1-SNAPSHOT/version
/plugin
/plugins
/pluginManagement
/build
modules
moduleexample-plugin/module
/modules
/project
{code:xml}
With {{release:prepare}}, the version of the example-plugin in the build
section stays untouched.
BTW: Is the {{pluginManagement}} totally ignored? I even don't get an error,
if I use SNAPSHOT versions in the {{pluginManagement}} section.
--
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-557) release:prepare does not update the version of a reactor plugin
[
https://jira.codehaus.org/browse/MRELEASE-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-557:
Description:
For example this pom.
{code:xml}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdexample/groupId
artifactIdexample-parent/artifactId
version0.0.1-SNAPSHOT/version
packagingpom/packaging
build
pluginManagement
plugins
plugin
groupIdexample/groupId
artifactIdexample-plugin/artifactId
version0.0.1-SNAPSHOT/version
/plugin
/plugins
/pluginManagement
/build
modules
moduleexample-plugin/module
/modules
/project
{code}
With {{release:prepare}}, the version of the example-plugin in the build
section stays untouched.
BTW: Is the {{pluginManagement}} totally ignored? I even don't get an error, if
I use SNAPSHOT versions in the {{pluginManagement}} section.
was:
For example this pom.
{code:xml}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdexample/groupId
artifactIdexample-parent/artifactId
version0.0.1-SNAPSHOT/version
packagingpom/packaging
build
pluginManagement
plugins
plugin
groupIdexample/groupId
artifactIdexample-plugin/artifactId
version0.0.1-SNAPSHOT/version
/plugin
/plugins
/pluginManagement
/build
modules
moduleexample-plugin/module
/modules
/project
{code:xml}
With {{release:prepare}}, the version of the example-plugin in the build
section stays untouched.
BTW: Is the {{pluginManagement}} totally ignored? I even don't get an error, if
I use SNAPSHOT versions in the {{pluginManagement}} section.
release:prepare does not update the version of a reactor plugin
---
Key: MRELEASE-557
URL: https://jira.codehaus.org/browse/MRELEASE-557
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0
Reporter: Frank Ressel
For example this pom.
{code:xml}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdexample/groupId
artifactIdexample-parent/artifactId
version0.0.1-SNAPSHOT/version
packagingpom/packaging
build
pluginManagement
plugins
plugin
groupIdexample/groupId
artifactIdexample-plugin/artifactId
version0.0.1-SNAPSHOT/version
/plugin
/plugins
/pluginManagement
/build
modules
moduleexample-plugin/module
/modules
/project
{code}
With {{release:prepare}}, the version of the example-plugin in the build
section stays untouched.
BTW: Is the {{pluginManagement}} totally ignored? I even don't get an error,
if I use SNAPSHOT versions in the {{pluginManagement}} section.
--
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-654) Release:perform fails on releasing a tag from an empty directory
[
https://jira.codehaus.org/browse/MRELEASE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300578#comment-300578
]
Robert Scholte commented on MRELEASE-654:
-
@Giacomo: is this correct? {{[INFO] Executing: /bin/sh -c cd
/tmp/$\{project.basedir\}/target svn --non-interactive checkout
https://srvdevel.unimatica.lan/svn/unilet/tags/unilet-base-5.3.13
'/tmp/$\{project.basedir\}/target/checkout'}}
Since you're running in debug mode, I'd expect to see some more feedback from
the scm-provider. It looks to me like nothing is checked out, so that would
explain why the plugin fails.
@Conan: I'm using Maven with equivalent environment without problems. It looks
like a different issue, so please make a new issue with a small test-project,
so we can reproduce your issue.
Release:perform fails on releasing a tag from an empty directory
Key: MRELEASE-654
URL: https://jira.codehaus.org/browse/MRELEASE-654
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.1
Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
OS name: linux, version: 2.6.35-25-generic, arch: amd64, family: unix
Reporter: Giacomo Boccardo
If we release our project from the same directory when we executed the
release:prepare the perform phase completes successfully, while performing a
release from a tag (in an empty directory) we have the following stack trace:
{noformat}
$ mvn release:perform -Dtag=unilet-base-5.3.13
-DconnectionUrl=scm:svn:https://srvdevel.unimatica.lan/svn/unilet -X
Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 2.6.35-25-generic, arch: amd64, family: unix
[INFO] Error stacktraces are turned on.
[DEBUG] Reading global settings from /usr/local/app/maven/conf/settings.xml
[DEBUG] Reading user settings from /home/gboccardo/.m2/settings.xml
[DEBUG] Using local repository at /home/gboccardo/.m2/repository
[DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10 for
/home/gboccardo/.m2/repository
[INFO] Scanning for projects...
[DEBUG] Extension realms for project org.apache.maven:standalone-pom:pom:1:
(none)
[DEBUG] Looking up lifecyle mappings for packaging pom from
ClassRealm[plexus.core, parent: null]
[DEBUG] Resolving plugin prefix release from [org.apache.maven.plugins,
org.codehaus.mojo]
[DEBUG] Resolved plugin prefix release to
org.apache.maven.plugins:maven-release-plugin from POM
org.apache.maven:standalone-pom:pom:1
[DEBUG] === REACTOR BUILD PLAN
[DEBUG] Project: org.apache.maven:standalone-pom:pom:1
[DEBUG] Tasks: [release:perform]
[DEBUG] Style: Aggregating
[DEBUG]
===
[INFO]
[INFO]
[INFO] Building Maven Stub Project (No POM) 1
[INFO]
[DEBUG] Resolving plugin prefix release from [org.apache.maven.plugins,
org.codehaus.mojo]
[DEBUG] Resolved plugin prefix release to
org.apache.maven.plugins:maven-release-plugin from POM
org.apache.maven:standalone-pom:pom:1
[DEBUG] Lifecycle default - [validate, initialize, generate-sources,
process-sources, generate-resources, process-resources, compile,
process-classes, generate-test-sources, process-test-sources,
generate-test-resources, process-test-resources, test-compile,
process-test-classes, test, prepare-package, package, pre-integration-test,
integration-test, post-integration-test, verify, install, deploy]
[DEBUG] Lifecycle clean - [pre-clean, clean, post-clean]
[DEBUG] Lifecycle site - [pre-site, site, post-site, site-deploy]
[DEBUG] === PROJECT BUILD PLAN
[DEBUG] Project: org.apache.maven:standalone-pom:1
[DEBUG] Dependencies (collect): []
[DEBUG] Dependencies (resolve): []
[DEBUG] Repositories (dependencies): [unimatica-m2-snapshot-repository
(http://coderepository.unimatica.lan/dev2/maven2-snapshot, releases=true,
snapshots=true, managed=false), unimatica-m2-coderepository
(http://coderepository.unimatica.lan/dev2/maven2, releases=true,
snapshots=true, managed=false), central (http://repo1.maven.org/maven2,
releases=true, snapshots=false, managed=false)]
[DEBUG] Repositories (plugins) : [central
[jira] (MRELEASE-557) release:prepare does not update the version of a reactor plugin
[
https://jira.codehaus.org/browse/MRELEASE-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-557.
---
Resolution: Cannot Reproduce
Assignee: Robert Scholte
The project contains several integration-tests:
{{maven-release-manager/src/test/resources/projects/*/internal-managed-snapshot-plugin/}}
These reflect exactly your usecase and succeed.
release:prepare does not update the version of a reactor plugin
---
Key: MRELEASE-557
URL: https://jira.codehaus.org/browse/MRELEASE-557
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0
Reporter: Frank Ressel
Assignee: Robert Scholte
For example this pom.
{code:xml}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdexample/groupId
artifactIdexample-parent/artifactId
version0.0.1-SNAPSHOT/version
packagingpom/packaging
build
pluginManagement
plugins
plugin
groupIdexample/groupId
artifactIdexample-plugin/artifactId
version0.0.1-SNAPSHOT/version
/plugin
/plugins
/pluginManagement
/build
modules
moduleexample-plugin/module
/modules
/project
{code}
With {{release:prepare}}, the version of the example-plugin in the build
section stays untouched.
BTW: Is the {{pluginManagement}} totally ignored? I even don't get an error,
if I use SNAPSHOT versions in the {{pluginManagement}} section.
--
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-760) updateWorkingCopyVersions=false still bumps up pom versions to next development version
[ https://jira.codehaus.org/browse/MRELEASE-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reopened MRELEASE-760: - updateWorkingCopyVersions=false still bumps up pom versions to next development version --- Key: MRELEASE-760 URL: https://jira.codehaus.org/browse/MRELEASE-760 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.3 Reporter: Joeri Leemans Assignee: Robert Scholte Fix For: 2.3.2 Attachments: maven-release-plugin-testcase.zip, mrelease760-patch.diff The flag updateWorkingCopyVersions (more specifically with value false) is not handled correctly. Attached project is a simple Maven project with version 1.0-SNAPSHOT, depending on version 2.3 of the release plugin. It is configured with dryRun=true and updateWorkingCopyVersions=false. When running mvn:prepare (and accepting the versions that are proposed), you'll see that pom.xml.next file contains 1.1-SNAPSHOT (the next development version) instead of 1.0 (the tagged version). -- 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-760) updateWorkingCopyVersions=false still bumps up pom versions to next development version
[ https://jira.codehaus.org/browse/MRELEASE-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-760. --- Resolution: Fixed Fixed in [r1348226|http://svn.apache.org/viewvc?rev=1348226view=rev]. Thanks for the unit-test. I've synced the developmentVersion with the branchVersion, which I prefer because it has less variables in the if-statement updateWorkingCopyVersions=false still bumps up pom versions to next development version --- Key: MRELEASE-760 URL: https://jira.codehaus.org/browse/MRELEASE-760 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.3 Reporter: Joeri Leemans Assignee: Robert Scholte Fix For: 2.3.2 Attachments: maven-release-plugin-testcase.zip, mrelease760-patch.diff The flag updateWorkingCopyVersions (more specifically with value false) is not handled correctly. Attached project is a simple Maven project with version 1.0-SNAPSHOT, depending on version 2.3 of the release plugin. It is configured with dryRun=true and updateWorkingCopyVersions=false. When running mvn:prepare (and accepting the versions that are proposed), you'll see that pom.xml.next file contains 1.1-SNAPSHOT (the next development version) instead of 1.0 (the tagged version). -- 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-663) Null error when project is too close to root
[
https://jira.codehaus.org/browse/MRELEASE-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-663:
Description:
Co-worker ran into issues where if he had checked out his project directly in
his root dir {{C:\}} (top pom ending up in {{C:\project\pom.xml}}) and ran the
{{release:prepare}} goal he would rather quickly recieve this error:
{noformat}
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at org.apache.maven.shared.release.util.ReleaseUtil.getBaseWorkingDirect
oryParentCount(ReleaseUtil.java:233)
at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.tran
slateScm(RewritePomsForReleasePhase.java:109)
at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.tran
sformScm(RewritePomsForReleasePhase.java:62)
at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transf
ormDocument(AbstractRewritePomsPhase.java:303)
at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transf
ormProject(AbstractRewritePomsPhase.java:208)
at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transf
orm(AbstractRewritePomsPhase.java:114)
at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execut
e(AbstractRewritePomsPhase.java:97)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:203)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:140)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:103)
at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(Pr
epareReleaseMojo.java:211)
at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareRe
leaseMojo.java:181)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:694)
{noformat}
I looked into it and eventually had him add a buffer directory so his top pom
was resting in {{C:\workspace\project\pom.xml}} and following this move it
built properly. Not sure if there is a real requirement to have this buffer
directory, but a better error message would be helpful.
was:
Co-worker ran into issues where if he had checked out his project directly in
his root dir C:\ (top pom ending up in C:\project\pom.xml) and ran the
release:prepare goal he would rather quickly recieve this error:
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at org.apache.maven.shared.release.util.ReleaseUtil.getBaseWorkingDirect
oryParentCount(ReleaseUtil.java:233)
at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.tran
slateScm(RewritePomsForReleasePhase.java:109)
at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.tran
sformScm(RewritePomsForReleasePhase.java:62)
at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transf
ormDocument(AbstractRewritePomsPhase.java:303)
at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transf
ormProject(AbstractRewritePomsPhase.java:208)
at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transf
orm(AbstractRewritePomsPhase.java:114)
at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execut
e(AbstractRewritePomsPhase.java:97)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:203)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:140)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:103)
at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(Pr
epareReleaseMojo.java:211)
at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareRe
leaseMojo.java:181)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:694)
I looked into it and eventually had him add a buffer directory so his top pom
was resting in C:\workspace\project\pom.xml and following this move it built
properly. Not sure
[jira] (MRELEASE-769) Release:prepare fails on Windows when commonBaseDir of all reactor projects is root drive (e.g. D:\)
[
https://jira.codehaus.org/browse/MRELEASE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-769.
---
Resolution: Duplicate
Assignee: Robert Scholte
Release:prepare fails on Windows when commonBaseDir of all reactor projects
is root drive (e.g. D:\)
Key: MRELEASE-769
URL: https://jira.codehaus.org/browse/MRELEASE-769
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.3.1
Environment: Windows 7 x64, Maven 3.0.4, Maven Release Plugin 2.3.1
Reporter: Conan Cook
Assignee: Robert Scholte
Attachments: ReleaseUtil_WindowsRootPatch
When running a release:prepare for a project in the RewritePomsForRelease
phase, a NullPointerException is thrown when calculating the number of parent
folders above the project root (part of the . This occurs when the reactor
projects have a commonBaseDir that is the root drive - in my case D: . This
is because the commonBaseDir is calculated to be D:, whereas the
java.io.File.getParentFile() method used in
ReleaseUtil.getBaseWorkingDirectoryParentCount() returns D:\ when it gets
to the root. As a result the equality comparison between these directories
fails, and the method continues looking above that location for a parent
folder, resulting in the NPE.
This can be reproduced by creating a reactor build where projects in the
reactor only share a commonBaseDir which is a Windows root drive - I haven't
included a test case because it's dependent on where you put it, not what it
contains.
I've attached a patch which normalises the commonBaseDir name by adding a
trailing slash, in ReleaseUtil.java in the Maven Release Manager project.
This could also be done after line 310 of the AbstractRewritePomsPhase, where
the variable is originally assigned, but the ReleaseUtil.getCommonBasedir()
method explicitly removes the trailing slash, so it seemed best to do it as
close to the problem as possible.
Stack trace from mvn -DdryRun=true release:prepare -X
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.1:prepare (default-cli) on
project amee-platform-api: Execution default-cli of goal
org.apache.maven.plugins:maven-release-plugin:2.3.1:prepare failed.
NullPointerException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-release-plugin:2.3.1:prepare
(default-cli) on project amee-platform-api: Execution default-cli of goal
org.apache.maven.plugins:maven-release-plugin:2.3.1:prepare 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.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.PluginExecutionException: Execution
default-cli of goal
org.apache.maven.plugins:maven-release-plugin:2.3.1:prepare failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
[jira] (MRELEASE-663) Null error when project is too close to root
[
https://jira.codehaus.org/browse/MRELEASE-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-663.
---
Resolution: Fixed
Fix Version/s: 2.3.2
Assignee: Robert Scholte
Fixed in [r1348252|http://svn.apache.org/viewvc?rev=1348252view=rev] based on
the analyses of MRELEASE-769
Null error when project is too close to root
Key: MRELEASE-663
URL: https://jira.codehaus.org/browse/MRELEASE-663
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Environment: Maven 2.2.1, Windows XP SP3
Reporter: Brent Smith
Assignee: Robert Scholte
Priority: Minor
Fix For: 2.3.2
Co-worker ran into issues where if he had checked out his project directly in
his root dir {{C:\}} (top pom ending up in {{C:\project\pom.xml}}) and ran
the {{release:prepare}} goal he would rather quickly recieve this error:
{noformat}
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.shared.release.util.ReleaseUtil.getBaseWorkingDirect
oryParentCount(ReleaseUtil.java:233)
at
org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.tran
slateScm(RewritePomsForReleasePhase.java:109)
at
org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.tran
sformScm(RewritePomsForReleasePhase.java:62)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transf
ormDocument(AbstractRewritePomsPhase.java:303)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transf
ormProject(AbstractRewritePomsPhase.java:208)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transf
orm(AbstractRewritePomsPhase.java:114)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execut
e(AbstractRewritePomsPhase.java:97)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:203)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:140)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(Default
ReleaseManager.java:103)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(Pr
epareReleaseMojo.java:211)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareRe
leaseMojo.java:181)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:694)
{noformat}
I looked into it and eventually had him add a buffer directory so his top
pom was resting in {{C:\workspace\project\pom.xml}} and following this move
it built properly. Not sure if there is a real requirement to have this
buffer directory, but a better error message would be helpful.
--
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-573) cannot release a multi-module project with maven3
[
https://jira.codehaus.org/browse/MRELEASE-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-573:
Description:
{{release:prepare}} produces the following exception. I am releasing a multi
module project. All modules have the {{2.3.3-SNAPSHOT}} Here is the stack
trace:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) on
project master: The version could not be updated: 2.3.3 - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) on
project master: The version could not be updated: 2.3.3
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:137)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:77)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:69)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:82)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:54)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.singleThreadedBuild(DefaultLifecycleExecutor.java:218)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:190)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:246)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:95)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:430)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:160)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:124)
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:31)
Caused by: org.apache.maven.plugin.MojoFailureException: The version could not
be updated: 2.3.3
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:219)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:181)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:133)
... 20 more
Caused by: org.apache.maven.shared.release.ReleaseFailureException: The version
could not be updated: 2.3.3
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.updateDomVersion(AbstractRewritePomsPhase.java:671)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.rewritePlugins(AbstractRewritePomsPhase.java:456)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:281)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:208)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:114)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:97)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:203)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:211)
... 23 more
[ERROR]
{noformat}
was:
release:prepare produces the following exception. I am releasing a multi module
project. All modules have the 2.3.3-SNAPSHOT Here is the stack trace:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) on
project master: The version could not be updated: 2.3.3 - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) on
project master: The version could not be
[jira] (MRELEASE-573) cannot release a multi-module project with maven3
[
https://jira.codehaus.org/browse/MRELEASE-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-573.
---
Resolution: Cannot Reproduce
Assignee: Robert Scholte
I've done several releases with final versions of Maven-3.0.x without any
problem, so closing it as 'cannot reproduce'.
cannot release a multi-module project with maven3
-
Key: MRELEASE-573
URL: https://jira.codehaus.org/browse/MRELEASE-573
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0
Environment: macos, java6, maven3-beta1
Reporter: Rares Pop
Assignee: Robert Scholte
{{release:prepare}} produces the following exception. I am releasing a multi
module project. All modules have the {{2.3.3-SNAPSHOT}} Here is the stack
trace:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) on
project master: The version could not be updated: 2.3.3 - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli)
on project master: The version could not be updated: 2.3.3
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:137)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:77)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:69)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:82)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:54)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.singleThreadedBuild(DefaultLifecycleExecutor.java:218)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:190)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:246)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:95)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:430)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:160)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:124)
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:31)
Caused by: org.apache.maven.plugin.MojoFailureException: The version could
not be updated: 2.3.3
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:219)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:181)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:133)
... 20 more
Caused by: org.apache.maven.shared.release.ReleaseFailureException: The
version could not be updated: 2.3.3
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.updateDomVersion(AbstractRewritePomsPhase.java:671)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.rewritePlugins(AbstractRewritePomsPhase.java:456)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:281)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:208)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:114)
at
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:97)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:203)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
at
[jira] (MRELEASE-770) ScmCheckModificationsPhase doesn't pick up ScmTranslator for relative path translation
Robert Scholte created MRELEASE-770: --- Summary: ScmCheckModificationsPhase doesn't pick up ScmTranslator for relative path translation Key: MRELEASE-770 URL: https://jira.codehaus.org/browse/MRELEASE-770 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.3.1 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] (MRELEASE-770) ScmCheckModificationsPhase doesn't pick up ScmTranslator for relative path translation
[ https://jira.codehaus.org/browse/MRELEASE-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-770. --- Resolution: Fixed Fix Version/s: 2.3.2 Assignee: Robert Scholte Fixed in [r1348555|http://svn.apache.org/viewvc?rev=1348555view=rev] ScmCheckModificationsPhase doesn't pick up ScmTranslator for relative path translation -- Key: MRELEASE-770 URL: https://jira.codehaus.org/browse/MRELEASE-770 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.3.1 Reporter: Robert Scholte Assignee: Robert Scholte Fix For: 2.3.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] (MRELEASE-484) release:rollback fails after branch with NPE and complaint about missing scm URL
[
https://jira.codehaus.org/browse/MRELEASE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-484.
---
Resolution: Fixed
Fix Version/s: 2.3.2
Assignee: Robert Scholte
Fixed in [r1348625|http://svn.apache.org/viewvc?rev=1348625view=rev]
The backup poms were created before the checks.
release:rollback fails after branch with NPE and complaint about missing scm
URL
Key: MRELEASE-484
URL: https://jira.codehaus.org/browse/MRELEASE-484
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: branch, rollback
Affects Versions: 2.0-beta-9
Reporter: Benson Margulies
Assignee: Robert Scholte
Fix For: 2.3.2
After a problem with release:branch (possibly the 'remoteTagging' problem) an
attempt to run rollback got me the following. The SCM urls are indeed in the
POM.
{noformat}
[INFO] Trace
java.lang.NullPointerException: The scm url cannot be null.
at
org.apache.maven.scm.manager.AbstractScmManager.makeScmRepository(AbstractScmManager.java:181)
at
org.apache.maven.shared.release.scm.DefaultScmRepositoryConfigurator.getConfiguredRepository(DefaultScmRepositoryConfigurator.java:62)
at
org.apache.maven.shared.release.phase.RestoreBackupPomsPhase.restorePomBackup(RestoreBackupPomsPhase.java:100)
at
org.apache.maven.shared.release.phase.RestoreBackupPomsPhase.execute(RestoreBackupPomsPhase.java:69)
at
org.apache.maven.shared.release.DefaultReleaseManager.rollback(DefaultReleaseManager.java:250)
at
org.apache.maven.shared.release.DefaultReleaseManager.rollback(DefaultReleaseManager.java:227)
at
org.apache.maven.plugins.release.RollbackReleaseMojo.execute(RollbackReleaseMojo.java:54)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
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:356)
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)
[INFO]
{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] (MRELEASE-756) release:prepare ignores properties from settings.xml
[
https://jira.codehaus.org/browse/MRELEASE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-756.
---
Resolution: Not A Bug
Assignee: Robert Scholte
It's not a maven-release-plugin bug, but a Maven bug. Upgrading to at least
maven-3.0.4 fixes this issue.
release:prepare ignores properties from settings.xml
Key: MRELEASE-756
URL: https://jira.codehaus.org/browse/MRELEASE-756
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.2.2
Environment: Maven 3.0.3, Win7, Java 1.6.0._32 64Bit
Reporter: Ralph Engelmann
Assignee: Robert Scholte
When I run {{release:prepare}}, then the properties defined in my maven
settings.xml in an active profile are not taken in account during the build.
{code:title=settings.xml}
...
profile
iddemo/id
properties
test.urljdbc:oracle:thin:@//java/xe/test.url
properties
profile
activeProfiles
activeProfiledemo/activeProfile
/activeProfiles
...
{code}
But the usage of ${test.url} in the pom.xml (when running release:prepare)
behaves like the property is not defined (it is not substituted).
But when using maven-release-plugin 2.2.1 the parameter is taken in account
like expected.
_I could not test, if release:perform has the same problem._
--
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-728) The commit message for release:branch is wrong
[ https://jira.codehaus.org/browse/MRELEASE-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-728. --- Resolution: Fixed Fix Version/s: 2.3 Assignee: Robert Scholte The commit message for release:branch is wrong -- Key: MRELEASE-728 URL: https://jira.codehaus.org/browse/MRELEASE-728 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch, Git Affects Versions: 2.2.1 Environment: git 1.7.5.4 Reporter: Adrien Ragot Assignee: Robert Scholte Fix For: 2.3 Using Git, when you do mvn release:branch -DbranchName=xxx, the commit message for master is [maven-release-plugin] prepare release xxx. The right commit message should be [maven-release-plugin] prepare branch xxx, like for Svn. -- 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-772) mvn release:prepare fails with IOException and a write error (Access is denied)
[
https://jira.codehaus.org/browse/MRELEASE-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301169#comment-301169
]
Robert Scholte commented on MRELEASE-772:
-
This is in fact a
[SCM#perforce|https://jira.codehaus.org/browse/SCM/component/11194]-issue. It
seems like the order of the arguments matter. The 'edit' is implemented, so it
looks like the behaviour has changed.
You should have a look at the
[PerforceEditCommand|http://maven.apache.org/scm/maven-scm-providers/maven-scm-provider-perforce/xref/org/apache/maven/scm/provider/perforce/command/edit/PerforceEditCommand.html],
which indeed adds the {{edit}} as final argument. That's where a fix should be
applied.
Further usage details, see
[maven-scm-provider-perforce|http://maven.apache.org/scm/maven-scm-providers/maven-scm-provider-perforce/index.html]
mvn release:prepare fails with IOException and a write error (Access is
denied)
---
Key: MRELEASE-772
URL: https://jira.codehaus.org/browse/MRELEASE-772
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.3.1
Environment: Windows 7 both command prompt and cygwin using Perforce
for SCM
Reporter: Svend Hansen
Attachments: maven-release-error.txt,
mvn_release_output_x_client_env.txt, mvn_release_output_x.txt
When running
{{mvn release:prepare -Dusername=perforce_user
-Dpassword=perforce_password}}
I get the errors:
* java.io.IOException: The filename, directory name, or volume label syntax
is incorrect
* [ERROR] CommandLineException Exit code: 1 - Usage: add/edit/delete [-c
changelist#] [ -d -f -k -n -v ] [-t type] files...
Missing/wrong number of arguments.
* [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.1:prepare (default-cli) on
project root-project: Error writing POM: D:\Server\pom.xml (Access is denied)
- [Help 1]
The full output is attached.
Sometimes I also get the error:
* [ERROR] D:\Server\pom.xml - file(s) not in client view.
Though I created the client in the same location I'm running from, and I'm
not sure that error is related to the others (as the others also occur when
that one doesn't).
It's been suggested (on stackoverflow:
http://stackoverflow.com/questions/10999403/maven-releaseprepare-ioexception)
that the error has to do with my D drive being a mapped drive, though I don't
think it is as it's not listed if I run {{subst}}. However, I think it _must_
be at least a partition on the same hard drive, unless my PC has three
physical drives :P (work PC), but I guess that shouldn't make any difference
to the program?
--
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-774) CLONE - mvn release:prepare fails with IOException and a write error (Access is denied)
Robert Scholte created MRELEASE-774:
---
Summary: CLONE - mvn release:prepare fails with IOException and a
write error (Access is denied)
Key: MRELEASE-774
URL: https://jira.codehaus.org/browse/MRELEASE-774
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.3.1
Environment: Windows 7 both command prompt and cygwin using Perforce
for SCM
Reporter: Robert Scholte
Attachments: maven-release-error.txt,
mvn_release_output_x_client_env.txt, mvn_release_output_x.txt
When running
{{mvn release:prepare -Dusername=perforce_user
-Dpassword=perforce_password}}
I get the errors:
* java.io.IOException: The filename, directory name, or volume label syntax is
incorrect
* [ERROR] CommandLineException Exit code: 1 - Usage: add/edit/delete [-c
changelist#] [ -d -f -k -n -v ] [-t type] files...
Missing/wrong number of arguments.
* [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.1:prepare (default-cli) on
project root-project: Error writing POM: D:\Server\pom.xml (Access is denied)
- [Help 1]
The full output is attached.
Sometimes I also get the error:
* [ERROR] D:\Server\pom.xml - file(s) not in client view.
Though I created the client in the same location I'm running from, and I'm not
sure that error is related to the others (as the others also occur when that
one doesn't).
It's been suggested (on stackoverflow:
http://stackoverflow.com/questions/10999403/maven-releaseprepare-ioexception)
that the error has to do with my D drive being a mapped drive, though I don't
think it is as it's not listed if I run {{subst}}. However, I think it _must_
be at least a partition on the same hard drive, unless my PC has three physical
drives :P (work PC), but I guess that shouldn't make any difference to the
program?
--
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-678) CLONE - mvn release:prepare fails with IOException and a write error (Access is denied)
[
https://jira.codehaus.org/browse/SCM-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte moved MRELEASE-774 to SCM-678:
-
Complexity: Intermediate
Component/s: (was: prepare)
maven-scm-provider-perforce
Affects Version/s: (was: 2.3.1)
1.7
Key: SCM-678 (was: MRELEASE-774)
Project: Maven SCM (was: Maven 2.x Release Plugin)
CLONE - mvn release:prepare fails with IOException and a write error (Access
is denied)
---
Key: SCM-678
URL: https://jira.codehaus.org/browse/SCM-678
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-perforce
Affects Versions: 1.7
Environment: Windows 7 both command prompt and cygwin using Perforce
for SCM
Reporter: Robert Scholte
Attachments: maven-release-error.txt,
mvn_release_output_x_client_env.txt, mvn_release_output_x.txt
When running
{{mvn release:prepare -Dusername=perforce_user
-Dpassword=perforce_password}}
I get the errors:
* java.io.IOException: The filename, directory name, or volume label syntax
is incorrect
* [ERROR] CommandLineException Exit code: 1 - Usage: add/edit/delete [-c
changelist#] [ -d -f -k -n -v ] [-t type] files...
Missing/wrong number of arguments.
* [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.1:prepare (default-cli) on
project root-project: Error writing POM: D:\Server\pom.xml (Access is denied)
- [Help 1]
The full output is attached.
Sometimes I also get the error:
* [ERROR] D:\Server\pom.xml - file(s) not in client view.
Though I created the client in the same location I'm running from, and I'm
not sure that error is related to the others (as the others also occur when
that one doesn't).
It's been suggested (on stackoverflow:
http://stackoverflow.com/questions/10999403/maven-releaseprepare-ioexception)
that the error has to do with my D drive being a mapped drive, though I don't
think it is as it's not listed if I run {{subst}}. However, I think it _must_
be at least a partition on the same hard drive, unless my PC has three
physical drives :P (work PC), but I guess that shouldn't make any difference
to the program?
--
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-507) Execute tests before tagging
[ https://jira.codehaus.org/browse/MRELEASE-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-507. --- Resolution: Cannot Reproduce Assignee: Robert Scholte Execute tests before tagging Key: MRELEASE-507 URL: https://jira.codehaus.org/browse/MRELEASE-507 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0-beta-9 Reporter: Paul Benedict Assignee: Robert Scholte Preparing a release waits to execute tests until after the tag. If the tagging succeeds but the tests fail, the commit created a tag with failing tests, and the build fails altogether. I recommend the test phase should run before the tag... yes, in addition (or as a replacement) after the tagging phase. -- 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-489) Cant Release project due to non released dependencies
[ https://jira.codehaus.org/browse/MRELEASE-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-489. --- Resolution: Incomplete Assignee: Robert Scholte No feedback from user for several years, so closing it as 'incomplete' Cant Release project due to non released dependencies - Key: MRELEASE-489 URL: https://jira.codehaus.org/browse/MRELEASE-489 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Reporter: Rajesh Sivagurunathan Assignee: Robert Scholte Attachments: effective.pom Hi, I am running /sbcimp/run/pd/maven/2.0.6/bin/mvn release:prepare --batch-mode -P fast ( profile to ignore tests).But it fails with the below error message. but the fact is we dont have any SNAPSHOT dependency setup in projects pom.xml file. But still we are getting this. Also, it started happened recently not from the beggining. So, can some one tell on which cases we will get this error? But sure that nothing has dependency like SNAPSHOT etc., If I remove the --batch-mode option and chose to resolve the project depedencies while it asks it runs fine. So, if anyone has any info of what it tries to remove as well will be great. [INFO] [INFO] Building fmm-credit [INFO]task-segment: [release:prepare] (aggregator-style) [INFO] [INFO] [release:prepare] [INFO] Verifying that there are no local modifications... [INFO] Executing: svn --non-interactive status [INFO] Working directory: /sbclocal/teamcity/QABuild/07_10_2009_16_05/credit-1.4.2.x [INFO] Checking dependencies and plugins for snapshots ... [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Can't release project due to non released dependencies : active project artifact: artifact = com.ubs.fmm.core:fmm-core-common:jar:1.4.2.1-SNAPSHOT:compile; project: org.apache.maven.project.MavenProject@137052d8 in project 'fmm-sec-pricing-web' (com.ubs.fmm.securities:fmm-sec-pricing-web:jar:1.4.2.1-SNAPSHOT) -- 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-269) Check that 'new development version' is a SNAPSHOT version
[ https://jira.codehaus.org/browse/MRELEASE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MRELEASE-269: Priority: Major (was: Trivial) Assignee: Robert Scholte I'm increasing the priority because I noticed that a fix for MRELEASE-511 would slightly change the behaviour of the plugin. Up until version 2.3.2 you could specify a snapshot as the release version from commandline. From this version the non-snapshot version was extracted and passed as the release version. I consider that as a bug, so with the implementation of this issue we can prevent invalid versions. Check that 'new development version' is a SNAPSHOT version --- Key: MRELEASE-269 URL: https://jira.codehaus.org/browse/MRELEASE-269 Project: Maven 2.x Release Plugin Issue Type: Wish Components: prepare Affects Versions: 2.0-beta-6 Reporter: Michael Meyer Assignee: Robert Scholte Labels: contributers-welcome Fix For: Backlog While executing 'mvn release:prepare' one gets asked for the new development version like this: What is the new development version for foo? (com.bar:foo) 1.12-SNAPSHOT: Say I want the new development version to be 2.0-SNAPSHOT (and not like suggested 1.12-SNAPSHOT) but by accident I only enter 2.0. This will work just fine until I want to execute 'mvn release:prepare' again at some later point. Then I will get the error message that the current version is not a SNAPSHOT version. It would be really nice if release:prepare could check if I have entered a valid SNAPSHOT version. If not release:prepare should fail or even nicer ask me to enter a proper SNAPSHOT version. -- 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:all-tabpanel
]
Robert Scholte reassigned MRELEASE-511:
---
Assignee: Robert Scholte
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\MyClientmvn -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.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
[jira] (SCM-678) CLONE - mvn release:prepare fails with IOException and a write error (Access is denied)
[
https://jira.codehaus.org/browse/SCM-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301374#comment-301374
]
Robert Scholte commented on SCM-678:
If I have a look at
[PerforceRemoveCommand|http://maven.apache.org/scm/maven-scm-providers/maven-scm-provider-perforce/xref/org/apache/maven/scm/provider/perforce/command/remove/PerforceRemoveCommand.html]
and
[PerforceAddCommand|http://maven.apache.org/scm/maven-scm-providers/maven-scm-provider-perforce/xref/org/apache/maven/scm/provider/perforce/command/add/PerforceAddCommand.html]
they don't seem to require those canonical paths.
According to the comment it's for testing purpose, but it seems to cause
trouble.
Could you create a Junit test with patch?
CLONE - mvn release:prepare fails with IOException and a write error (Access
is denied)
---
Key: SCM-678
URL: https://jira.codehaus.org/browse/SCM-678
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-perforce
Affects Versions: 1.7
Environment: Windows 7 both command prompt and cygwin using Perforce
for SCM
Reporter: Robert Scholte
Attachments: maven-release-error.txt,
mvn_release_output_x_client_env.txt, mvn_release_output_x.txt
When running
{{mvn release:prepare -Dusername=perforce_user
-Dpassword=perforce_password}}
I get the errors:
* java.io.IOException: The filename, directory name, or volume label syntax
is incorrect
* [ERROR] CommandLineException Exit code: 1 - Usage: add/edit/delete [-c
changelist#] [ -d -f -k -n -v ] [-t type] files...
Missing/wrong number of arguments.
* [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.1:prepare (default-cli) on
project root-project: Error writing POM: D:\Server\pom.xml (Access is denied)
- [Help 1]
The full output is attached.
Sometimes I also get the error:
* [ERROR] D:\Server\pom.xml - file(s) not in client view.
Though I created the client in the same location I'm running from, and I'm
not sure that error is related to the others (as the others also occur when
that one doesn't).
It's been suggested (on stackoverflow:
http://stackoverflow.com/questions/10999403/maven-releaseprepare-ioexception)
that the error has to do with my D drive being a mapped drive, though I don't
think it is as it's not listed if I run {{subst}}. However, I think it _must_
be at least a partition on the same hard drive, unless my PC has three
physical drives :P (work PC), but I guess that shouldn't make any difference
to the program?
--
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-396) release:branch goal does not honor autoVersionSubmodules=true configuration property
[
https://jira.codehaus.org/browse/MRELEASE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-396.
---
Resolution: Duplicate
Assignee: Robert Scholte
release:branch goal does not honor autoVersionSubmodules=true configuration
property
Key: MRELEASE-396
URL: https://jira.codehaus.org/browse/MRELEASE-396
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: branch
Affects Versions: 2.0-beta-8
Environment: multi-module build
Reporter: Ian Springer
Assignee: Robert Scholte
In my pom, I have:
{code:xml}
plugin
artifactIdmaven-release-plugin/artifactId
configuration
autoVersionSubmodulestrue/autoVersionSubmodules
updateDependenciesfalse/updateDependencies
/configuration
/plugin
{code}
Yet, when I run:
{{mvn release:branch -DbranchName=JBossON_2_1_2_SP
-DupdateBranchVersions=true -DupdateWorkingCopyVersions=false}}
I am still prompted for branch versions for all sub-modules in my reactor,
i.e.:
{noformat}
What is the branch version for JON? (org.jboss.on:jboss-on-parent)
2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
What is the branch version for JON Parent? (org.jboss.on:jon-parent)
2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
What is the branch version for JON Tomcat Plugin?
(org.jboss.on:rhq-tomcat-plugin) 2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
What is the branch version for JON JBossAS 3.2.x/4.x Plugin?
(org.jboss.on:rhq-jbossas-plugin) 2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
What is the branch version for JON Hibernate Plugin?
(org.jboss.on:rhq-hibernate-plugin) 2.1.2.GA-SNAPSHOT: : 2.1.2.SP1-SNAPSHOT
etc...
{noformat}
I also tried specifying autoVersionSubmodules=true via the command line to no
avail, i.e.:
{{mvn release:branch -DbranchName=JBossON_2_1_2_SP
-DupdateBranchVersions=true -DupdateWorkingCopyVersions=false
-DautoVersionSubmodules=true}}
--
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-678) CLONE - mvn release:prepare fails with IOException and a write error (Access is denied)
[
https://jira.codehaus.org/browse/SCM-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301446#comment-301446
]
Robert Scholte commented on SCM-678:
{quote}
How to I create a patch? Do I just commit my changes through SVN?
I can write a Junit test that breaks without my change, but works with... Or
should I just add another test method to the PerforceEditCommandTest and
PerforceCheckInCommandTest?
{quote}
You don't have the rights to commit, but creating a patch is just as simple.
Your IDE or tools like for instance tortoisesvn have the option 'create
patch/diff' next to the commit option.
If you'd prefer executions from command line, please check
[http://maven.apache.org/guides/development/guide-m2-development.html#Creating_and_submitting_a_patch]
CLONE - mvn release:prepare fails with IOException and a write error (Access
is denied)
---
Key: SCM-678
URL: https://jira.codehaus.org/browse/SCM-678
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-perforce
Affects Versions: 1.7
Environment: Windows 7 both command prompt and cygwin using Perforce
for SCM
Reporter: Robert Scholte
Attachments: maven-release-error.txt,
mvn_release_output_x_client_env.txt, mvn_release_output_x.txt
When running
{{mvn release:prepare -Dusername=perforce_user
-Dpassword=perforce_password}}
I get the errors:
* java.io.IOException: The filename, directory name, or volume label syntax
is incorrect
* [ERROR] CommandLineException Exit code: 1 - Usage: add/edit/delete [-c
changelist#] [ -d -f -k -n -v ] [-t type] files...
Missing/wrong number of arguments.
* [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.1:prepare (default-cli) on
project root-project: Error writing POM: D:\Server\pom.xml (Access is denied)
- [Help 1]
The full output is attached.
Sometimes I also get the error:
* [ERROR] D:\Server\pom.xml - file(s) not in client view.
Though I created the client in the same location I'm running from, and I'm
not sure that error is related to the others (as the others also occur when
that one doesn't).
It's been suggested (on stackoverflow:
http://stackoverflow.com/questions/10999403/maven-releaseprepare-ioexception)
that the error has to do with my D drive being a mapped drive, though I don't
think it is as it's not listed if I run {{subst}}. However, I think it _must_
be at least a partition on the same hard drive, unless my PC has three
physical drives :P (work PC), but I guess that shouldn't make any difference
to the program?
--
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-775) IllegalStateException while checking for modifications if multiple exclusion patterns match
[
https://jira.codehaus.org/browse/MRELEASE-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-775.
---
Resolution: Fixed
Fix Version/s: 2.4
Assignee: Robert Scholte
Fixed in [r1352317|http://svn.apache.org/viewvc?rev=1352317view=rev]
IllegalStateException while checking for modifications if multiple exclusion
patterns match
---
Key: MRELEASE-775
URL: https://jira.codehaus.org/browse/MRELEASE-775
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.3.2
Reporter: Arne Degenring
Assignee: Robert Scholte
Fix For: 2.4
Attachments: patch.txt
Within {{release:prepare}}, in the check SCM modifications phase, an
{{IllegalStateException}} occurs in case multiple exclusion patterns match.
In my case, I configured the {{release.properties}} to be ignored, even
though this is already ignored by default.
The bug is at
{{org.apache.maven.shared.release.phase.ScmCheckModificationsPhase.execute(ScmCheckModificationsPhase.java:169)}}
where {{Iterator.remove()}} is called from within the for-loop. If multiple
patterns match, {{Iterator.remove()}} is called multiple times which is of
course illegal.
To fix this, it should be enough to add a {{break}} after the
{{i.remove()}} call at
{{org.apache.maven.shared.release.phase.ScmCheckModificationsPhase.execute(ScmCheckModificationsPhase.java:169)}}.
See attached patch.
POM excerpt:
{code:xml}
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
configuration
checkModificationExcludes
checkModificationExcludebuild-number.txt/checkModificationExclude
checkModificationExcluderelease.properties/checkModificationExclude
checkModificationExcludepom.xml.versionsBackup/checkModificationExclude
/checkModificationExcludes
/configuration
/plugin
...
{code}
Stacktrace:
{noformat}
...
[DEBUG] ? release.properties
[DEBUG] Ignoring changed file: release.properties
[DEBUG] Ignoring changed file: release.properties
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[DEBUG] Trace
java.lang.IllegalStateException
at java.util.AbstractList$Itr.remove(AbstractList.java:356)
at
org.apache.maven.shared.release.phase.ScmCheckModificationsPhase.execute(ScmCheckModificationsPhase.java:169)
at
org.apache.maven.shared.release.phase.ScmCheckModificationsPhase.simulate(ScmCheckModificationsPhase.java:199)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:228)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:169)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:146)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:107)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:291)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:247)
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.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387
)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
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
[jira] (MRELEASE-775) IllegalStateException while checking for modifications if multiple exclusion patterns match
[
https://jira.codehaus.org/browse/MRELEASE-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-775:
Description:
Within {{release:prepare}}, in the check SCM modifications phase, an
{{IllegalStateException}} occurs in case multiple exclusion patterns match.
In my case, I configured the {{release.properties}} to be ignored, even though
this is already ignored by default.
The bug is at
{{org.apache.maven.shared.release.phase.ScmCheckModificationsPhase.execute(ScmCheckModificationsPhase.java:169)}}
where {{Iterator.remove()}} is called from within the for-loop. If multiple
patterns match, {{Iterator.remove()}} is called multiple times which is of
course illegal.
To fix this, it should be enough to add a {{break}} after the {{i.remove()}}
call at
{{org.apache.maven.shared.release.phase.ScmCheckModificationsPhase.execute(ScmCheckModificationsPhase.java:169)}}.
See attached patch.
POM excerpt:
{code:xml}
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
configuration
checkModificationExcludes
checkModificationExcludebuild-number.txt/checkModificationExclude
checkModificationExcluderelease.properties/checkModificationExclude
checkModificationExcludepom.xml.versionsBackup/checkModificationExclude
/checkModificationExcludes
/configuration
/plugin
...
{code}
Stacktrace:
{noformat}
...
[DEBUG] ? release.properties
[DEBUG] Ignoring changed file: release.properties
[DEBUG] Ignoring changed file: release.properties
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[DEBUG] Trace
java.lang.IllegalStateException
at java.util.AbstractList$Itr.remove(AbstractList.java:356)
at
org.apache.maven.shared.release.phase.ScmCheckModificationsPhase.execute(ScmCheckModificationsPhase.java:169)
at
org.apache.maven.shared.release.phase.ScmCheckModificationsPhase.simulate(ScmCheckModificationsPhase.java:199)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:228)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:169)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:146)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:107)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:291)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:247)
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.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387
)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
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)
{noformat}
was:
[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-tabpanelfocusedCommentId=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
developerConnectionscm:svn:svn://host/path/project/trunk/developerConnection
/scm
{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] (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-tabpanelfocusedCommentId=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] (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] (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] (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] (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-tabpanelfocusedCommentId=301678#comment-301678
]
Robert Scholte commented on MRELEASE-156:
-
FAQ improved in [r1352705|http://svn.apache.org/viewvc?rev=1352705view=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] (MCHANGES-176) Make ConversionTool available in the VelocityContext
[ https://jira.codehaus.org/browse/MCHANGES-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MCHANGES-176: --- Assignee: Robert Scholte Make ConversionTool available in the VelocityContext Key: MCHANGES-176 URL: https://jira.codehaus.org/browse/MCHANGES-176 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: announcement Affects Versions: 2.1 Reporter: Antonin Stefanutti Assignee: Robert Scholte Fix For: backlog It would be very useful to have access to an instance of ConversionTool in the Velocity templace so that one can convert String to List for example. See : http://velocity.apache.org/tools/devel/javadoc/org/apache/velocity/tools/generic/ConversionTool.html In my special case, I want to pass a list of packages as a comma-separated String in the announceParameters as configuration of the changes plugin and convert this comma-separated String as a List in the Velocity template to iterate over to send e-mails containing the packages I deployed in addition to the changes 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] (MCHANGES-176) Make ConversionTool available in the VelocityContext
[ https://jira.codehaus.org/browse/MCHANGES-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MCHANGES-176. --- Resolution: Fixed Fix Version/s: (was: backlog) 2.8 Fixed in [r1352964|http://svn.apache.org/viewvc?rev=1352964view=rev] Make ConversionTool available in the VelocityContext Key: MCHANGES-176 URL: https://jira.codehaus.org/browse/MCHANGES-176 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: announcement Affects Versions: 2.1 Reporter: Antonin Stefanutti Assignee: Robert Scholte Fix For: 2.8 It would be very useful to have access to an instance of ConversionTool in the Velocity templace so that one can convert String to List for example. See : http://velocity.apache.org/tools/devel/javadoc/org/apache/velocity/tools/generic/ConversionTool.html In my special case, I want to pass a list of packages as a comma-separated String in the announceParameters as configuration of the changes plugin and convert this comma-separated String as a List in the Velocity template to iterate over to send e-mails containing the packages I deployed in addition to the changes 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] (MRELEASE-138) release:prepare fails when checking in modified POMs of a multi-modules project
[
https://jira.codehaus.org/browse/MRELEASE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-138.
---
Resolution: Incomplete
Assignee: Robert Scholte (was: Emmanuel Venisse)
No feedback from users, closing it as {{incomplete}}
release:prepare fails when checking in modified POMs of a multi-modules
project
---
Key: MRELEASE-138
URL: https://jira.codehaus.org/browse/MRELEASE-138
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: scm
Affects Versions: 2.0-beta-4
Environment: WinXP + Eclipse
Reporter: ol
Assignee: Robert Scholte
Priority: Critical
Here is the project structure on the disk :
c:\javadev\prj\myproject\module1
c:\javadev\prj\myproject\module2
c:\javadev\prj\myproject\master
These 3 folders represent the 3 eclipse projects, each one containing a
pom.xml.
The master project's pom is the parent of the modules.
When I execute the release:prepare goal, Everything works fine (it asks to me
the tag name, the next dev version, ...) until I receive this error :
[INFO] Checking in modified POMs...
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An error is occurred in the checkin process:
C:\javadev\prj\myproject\module1\pom.xml was not contained in
C:\javadev\prj\myproject\master
[INFO]
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred
in the checkin process: C:\javadev\prj\myproject\module1\pom.xml was not
contained in C:\javadev\prj\myproject\master
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
The problem is that the project structure is the only one that can be used
with eclipse.
--
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-750) String index out of range: -1 in ReleaseUtils.loadResolvedDependencies() when using Parent-Module-Layout
[
https://jira.codehaus.org/browse/MRELEASE-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-750.
---
Resolution: Fixed
Fix Version/s: 2.4
Assignee: Robert Scholte
Fixed in [r1353035|http://svn.apache.org/viewvc?rev=1353035view=rev]
I've been able reproduce the {{StringIndexOutOfBOundsException}} and it exposed
another bug, which could solve a lot of other issues.
So I've been quite happy I did some investigation instead of going for the
defensive strategy.
Main reason was a wrong calculation of the {{startIndex}} and {{endIndex}}.
String index out of range: -1 in ReleaseUtils.loadResolvedDependencies() when
using Parent-Module-Layout
Key: MRELEASE-750
URL: https://jira.codehaus.org/browse/MRELEASE-750
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.3
Reporter: Thomas Baldauf
Assignee: Robert Scholte
Fix For: 2.4
Attachments: MNG-750-release.patch, ReleaseUtils.java
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.XXX:prepare (default-cli) on
project XXX: Execution default-cli of goal
org.apache.maven.plugins:maven-release-plugin:2.XXX:prepare failed: String
index out of range: -1 - [Help 1]
This is happening in
org.apache.maven.shared.release.config.ReleaseUtils.loadResolvedDependencies(..),
line number 250:
artifactVersionlessKey = propertyName.substring( startIndex, endIndex );
Apparently endIndex can be -1 under special circumstances. Defensive
programming fixes the problem.
Proposed patch (see attachment):
if (endIndex startIndex) {
artifactVersionlessKey = propertyName.substring( startIndex,
endIndex );
} else {
artifactVersionlessKey = propertyName.substring( startIndex );
}
--
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] (MPLUGIN-209) use maven-plugin-tools' java 5 annotations
[
https://jira.codehaus.org/browse/MPLUGIN-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301747#comment-301747
]
Robert Scholte commented on MPLUGIN-209:
Could it be that this commit causes the {{HelpMojo}} to be generated in the
root of generated sources (package-less)?
use maven-plugin-tools' java 5 annotations
--
Key: MPLUGIN-209
URL: https://jira.codehaus.org/browse/MPLUGIN-209
Project: Maven 2.x Plugin Tools
Issue Type: Task
Components: Plugin Plugin
Affects Versions: 3.0
Reporter: Herve Boutemy
Assignee: Herve Boutemy
Fix For: 3.1
apply to self :)
--
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-619) release:branch doesn't work as expected with multi-module projects
[ https://jira.codehaus.org/browse/MRELEASE-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-619. --- Resolution: Fixed Fix Version/s: 2.4 Assignee: Robert Scholte Fixed in [r1353151|http://svn.apache.org/viewvc?rev=1353151view=rev] Thanks! release:branch doesn't work as expected with multi-module projects --- Key: MRELEASE-619 URL: https://jira.codehaus.org/browse/MRELEASE-619 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0, 2.1 Reporter: Emilio Jose Mena Cebrian Assignee: Robert Scholte Fix For: 2.4 Attachments: ScmBranchPhase.java.patch The goal release:branch doesn't work as release:prepare with multi-module projects with flat layout (with parent project and modules at same level in URL path) While release:prepare takes into account the project layout using ReleaseUtil.createBasedirAlignedReleaseDescriptor, the goal release:branch doesn't The involved calss is org.apache.maven.shared.release.phase.ScmBranchPhase which is similar to org.apache.maven.shared.release.phase.ScmTagPhase, so I've assumed I can invoke ReleaseUtil.createBasedirAlignedReleaseDescriptor to obtain the corrected ReleaseDescriptor. I've corrected this behaviour in a local copy of maven-release-manager module and seems to work, but i have not fully tested the patch The patch is relative to maven-release-manager module -- 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] (MSKINS-40) left column is too big since fluido 1.2
[ https://jira.codehaus.org/browse/MSKINS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSKINS-40. Resolution: Fixed Fix Version/s: fluido-1.2.2 Assignee: Robert Scholte Fixed in [r1353177|http://svn.apache.org/viewvc?rev=1353177view=rev] left column is too big since fluido 1.2 --- Key: MSKINS-40 URL: https://jira.codehaus.org/browse/MSKINS-40 Project: Maven Skins Issue Type: Bug Components: Fluido Skin Affects Versions: fluido-1.2, fluido-1.2.1 Reporter: Herve Boutemy Assignee: Robert Scholte Fix For: fluido-1.2.2 if you compare the rendered result from 1. fuido 1.1: http://maven.apache.org/skins/maven-fluido-skin-1.1/ 2. and fluido 1.2: http://maven.apache.org/skins/maven-fluido-skin-1.2/ the left column was well sized in 1.1 but has grown in 1.2 for non-obvious reasons -- 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] (MSKINS-41) Links from site.xml are rendered in reverse order
[
https://jira.codehaus.org/browse/MSKINS-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MSKINS-41.
Resolution: Fixed
Fix Version/s: fluido-1.2.2
Assignee: Robert Scholte
Fixed in [r1353196|http://svn.apache.org/viewvc?rev=1353196view=rev]
Thanks for the patch!
Links from site.xml are rendered in reverse order
--
Key: MSKINS-41
URL: https://jira.codehaus.org/browse/MSKINS-41
Project: Maven Skins
Issue Type: Bug
Components: Fluido Skin
Affects Versions: fluido-1.2
Reporter: Andreas Sewe
Assignee: Robert Scholte
Priority: Minor
Fix For: fluido-1.2.2
Attachments: mskins-41-it.patch
If one defines multiple links in the {{site.xml}} (project/body/links/item),
they are rendered in reverse order, i.e., what comes first in the
{{site.xml}} comes last in the rendered page.
--
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] (MSKINS-54) Upgrade to bootstrap-2.0.4
Robert Scholte created MSKINS-54: Summary: Upgrade to bootstrap-2.0.4 Key: MSKINS-54 URL: https://jira.codehaus.org/browse/MSKINS-54 Project: Maven Skins Issue Type: Improvement Components: Fluido Skin Affects Versions: fluido-1.2.1 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] (MSKINS-54) Upgrade to bootstrap-2.0.4
[
https://jira.codehaus.org/browse/MSKINS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301789#comment-301789
]
Robert Scholte commented on MSKINS-54:
--
Replacing the {{js}} and {{css}} has some side effects, it ruins the searchbox
for instance.
Upgrade to bootstrap-2.0.4
--
Key: MSKINS-54
URL: https://jira.codehaus.org/browse/MSKINS-54
Project: Maven Skins
Issue Type: Improvement
Components: Fluido Skin
Affects Versions: fluido-1.2.1
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] (MPLUGIN-217) HelpMojo (always) contains description for the maven-plugin-plugin
Robert Scholte created MPLUGIN-217:
--
Summary: HelpMojo (always) contains description for the
maven-plugin-plugin
Key: MPLUGIN-217
URL: https://jira.codehaus.org/browse/MPLUGIN-217
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 3.0
Reporter: Robert Scholte
The HelpMojo.java generated for the m-release-p contains the following
description:
{code}
/**
* Display help information on maven-plugin-plugin.br/
* Call codemvn plugin:help -Ddetail=true -Dgoal=lt;goal-namegt;/code to
display parameter details.
* @author
* @version
* @goal help
* @requiresProject false
* @threadSafe
*/
public class HelpMojo
extends AbstractMojo
{code}
This seems to be for the wrong 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] (MPLUGIN-217) HelpMojo (always) contains description for the maven-plugin-plugin
[
https://jira.codehaus.org/browse/MPLUGIN-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MPLUGIN-217:
--
Assignee: Robert Scholte
HelpMojo (always) contains description for the maven-plugin-plugin
---
Key: MPLUGIN-217
URL: https://jira.codehaus.org/browse/MPLUGIN-217
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 3.0
Reporter: Robert Scholte
Assignee: Robert Scholte
The HelpMojo.java generated for the m-release-p contains the following
description:
{code}
/**
* Display help information on maven-plugin-plugin.br/
* Call codemvn plugin:help -Ddetail=true -Dgoal=lt;goal-namegt;/code
to display parameter details.
* @author
* @version
* @goal help
* @requiresProject false
* @threadSafe
*/
public class HelpMojo
extends AbstractMojo
{code}
This seems to be for the wrong 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] (MRELEASE-653) Filter reactor projects that are concerned by a submodule branch operation
[
https://jira.codehaus.org/browse/MRELEASE-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301941#comment-301941
]
Robert Scholte commented on MRELEASE-653:
-
I have my doubts about this patch. This implementation won't work for flat
multi-modules projects.
Also, I don't think that nesting the release-plugin (that's what is actually
happening here) is a good idea.
IMO you should use the
[maven-invoker-plugin|http://maven.apache.org/plugins/maven-invoker-plugin/] to
fork a new Maven-call for the branch.
Filter reactor projects that are concerned by a submodule branch operation
--
Key: MRELEASE-653
URL: https://jira.codehaus.org/browse/MRELEASE-653
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: branch
Affects Versions: 2.1
Reporter: Lucien Weller
Attachments: filter-modules.patch
We have the requirement to create a separate branch of one submodule when
releasing the entire project. We solved this with the follwoing config in
pom.xml of concerned submodule:
{code:xml}
profile
idbranchSubModule/id
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
inheritedfalse/inherited
executions
execution
idexplorer-branch/id
inheritedfalse/inherited
phasepackage/phase
goals
goalbranch/goal
/goals
configuration
branchNamere${project.version}-submodule/branchName
developmentVersion${project.version}/developmentVersion
updateBranchVersionstrue/updateBranchVersions
releaseVersion${project.version}-00-SNAPSHOT/releaseVersion
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
{code}
We launch the release build of parent project with:
{{mvn release:prepare release:perform -DreleaseProfiles=branchSubModule}}
Beside issue adressed by MRELEASE-619, we also face the problem that all
submodules are affected when our special submodule gets branched.
We solved this issue by filtering reactor projects with the current working
path.
--
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] (MSKINS-40) left column is too big since fluido 1.2
[ https://jira.codehaus.org/browse/MSKINS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSKINS-40. Resolution: Fixed The fix in [r1354676|http://svn.apache.org/viewvc?rev=1354676view=rev] should do the trick left column is too big since fluido 1.2 --- Key: MSKINS-40 URL: https://jira.codehaus.org/browse/MSKINS-40 Project: Maven Skins Issue Type: Bug Components: Fluido Skin Affects Versions: fluido-1.2, fluido-1.2.1 Reporter: Herve Boutemy Assignee: Robert Scholte Fix For: fluido-1.2.2 if you compare the rendered result from 1. fuido 1.1: http://maven.apache.org/skins/maven-fluido-skin-1.1/ 2. and fluido 1.2: http://maven.apache.org/skins/maven-fluido-skin-1.2/ the left column was well sized in 1.1 but has grown in 1.2 for non-obvious reasons -- 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] (MSKINS-54) Upgrade to bootstrap-2.0.4
[ https://jira.codehaus.org/browse/MSKINS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSKINS-54. Resolution: Fixed Fix Version/s: fluido-1.2.2 Assignee: Robert Scholte Fixed in [r1354699|http://svn.apache.org/viewvc?rev=1354699view=rev] Fix of MSKINS-40 already repaired the searchbox. Box does has much smaller rounded corners, but I don't think that's an issue. Upgrade to bootstrap-2.0.4 -- Key: MSKINS-54 URL: https://jira.codehaus.org/browse/MSKINS-54 Project: Maven Skins Issue Type: Improvement Components: Fluido Skin Affects Versions: fluido-1.2.1 Reporter: Robert Scholte Assignee: Robert Scholte Fix For: fluido-1.2.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] (MSKINS-36) Website license link missing / incorrect
[
https://jira.codehaus.org/browse/MSKINS-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MSKINS-36.
Resolution: Won't Fix
Assignee: Robert Scholte
http://www.apache.org/licenses/ is a general page for all licenses, while now
we include a page containing exactly the content of the used license (which
contains the URL of the Apache license page you mentioned)
The {{license.html}} is generated the
[license-report|http://maven.apache.org/plugins/maven-project-info-reports-plugin/license-mojo.html],
the link is generated by the maven-site-plugin.
By replacing the link (if possible, I doubt it) you've lost the information
under which license the skin was released.
Website license link missing / incorrect
Key: MSKINS-36
URL: https://jira.codehaus.org/browse/MSKINS-36
Project: Maven Skins
Issue Type: Bug
Reporter: SebbASF
Assignee: Robert Scholte
All ASF product websites should have a prominent link to the Apache License
at
http://www.apache.org/licenses/
The project documentation / project information page has a link to
http://maven.apache.org/skins/maven-fluido-skin/license.html but that is
incorrect, the only license link should be to http://www.apache.org/licenses/
--
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] (MSKINS-51) Github ribbon image broken
[ https://jira.codehaus.org/browse/MSKINS-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSKINS-51. Resolution: Fixed Assignee: Robert Scholte Fixed in [r1354723|http://svn.apache.org/viewvc?rev=1354723view=rev] Github ribbon image broken -- Key: MSKINS-51 URL: https://jira.codehaus.org/browse/MSKINS-51 Project: Maven Skins Issue Type: Bug Components: Fluido Skin Affects Versions: fluido-1.2.1 Reporter: Julien Nicoulaud Assignee: Robert Scholte The Github ribbon image has changed address (example here: http://nicoulaj.github.com/checksum-maven-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] (MSKINS-53) add hook for custom script
[
https://jira.codehaus.org/browse/MSKINS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MSKINS-53.
Resolution: Won't Fix
Assignee: Robert Scholte
You can use the
[head|http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Inject_xhtml_into_head]
of the {{site.xml}} for that.
add hook for custom script
--
Key: MSKINS-53
URL: https://jira.codehaus.org/browse/MSKINS-53
Project: Maven Skins
Issue Type: Improvement
Components: Fluido Skin
Reporter: Paolo Mariotti
Assignee: Robert Scholte
would it be possible to add to the site.vm an hook for a custom script
(something like site.js) as it happens for the css?
--
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-618) use maven-plugin-tools' java 5 annotations
[
https://jira.codehaus.org/browse/MASSEMBLY-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=302095#comment-302095
]
Robert Scholte commented on MASSEMBLY-618:
--
{quote}@parameter expression=$\{project.build.directory\}/assembly/work{quote}
This was wrong and should have been a {{default-value}}.
Now that we use {{property}} instead of {{expression}} the difference should
finally be clear.
use maven-plugin-tools' java 5 annotations
--
Key: MASSEMBLY-618
URL: https://jira.codehaus.org/browse/MASSEMBLY-618
Project: Maven 2.x Assembly Plugin
Issue Type: Task
Affects Versions: 2.3
Reporter: Tony Chemit
Attachments: MASSEMBLY-618.diff
--
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-729) release:branch makes pom changes for branch in 'master' before branching
[
https://jira.codehaus.org/browse/MRELEASE-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-729:
Component/s: branch
release:branch makes pom changes for branch in 'master' before branching
Key: MRELEASE-729
URL: https://jira.codehaus.org/browse/MRELEASE-729
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: branch, Git
Affects Versions: 2.2.2
Reporter: Joseph Walton
{{release:branch}} makes the change for the branch version before branching.
This means the version change is seen in the trunk's history.
If master is currently '1-SNAPSHOT':
{code}
* 1-SNAPSHOT [master]
{code}
and I create a new 'branch-with-hacks' branch as '1.hacks-SNAPSHOT' then I'll
see this in my log:
{code}
* 1-SNAPSHOT [master]
|
* 1.hacks-SNAPSHOT [branch-with-hacks]
|
* 1-SNAPSHOT
{code}
with a commit and a revert on master where I would expect:
{code}
* 1.hacks-SNAPSHOT [branch-with-hacks]
|
* 1-SNAPSHOT [master]
{code}
with 'master' remaining unaffected.
--
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] (MWAR-282) use maven-plugin-tools' java 5 annotations
[ https://jira.codehaus.org/browse/MWAR-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MWAR-282: --- Assignee: Robert Scholte use maven-plugin-tools' java 5 annotations -- Key: MWAR-282 URL: https://jira.codehaus.org/browse/MWAR-282 Project: Maven 2.x WAR Plugin Issue Type: Task Affects Versions: 2.1.1 Reporter: Tony Chemit Assignee: Robert Scholte Attachments: MWAR-282.diff -- 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] (MWAR-282) use maven-plugin-tools' java 5 annotations
[
https://jira.codehaus.org/browse/MWAR-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MWAR-282.
---
Resolution: Fixed
Fix Version/s: 2.2
Fixed in [r1355570|http://svn.apache.org/viewvc?rev=1355570view=rev]
I did some small modifications:
* I kept the pom in sync with its parent, just upgrading the versions when
required.
* {{project}}, {{session}}, and {{settings}} are special parameters
(required+readonly). These can be annotated with {{@Component}}, so I did. If I
had found the page with these special parameters I would have given it to you,
but I haven't found it yet.
Anyhow, thanks a lot!
use maven-plugin-tools' java 5 annotations
--
Key: MWAR-282
URL: https://jira.codehaus.org/browse/MWAR-282
Project: Maven 2.x WAR Plugin
Issue Type: Task
Affects Versions: 2.1.1
Reporter: Tony Chemit
Assignee: Robert Scholte
Fix For: 2.2
Attachments: MWAR-282.diff
--
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] (MWAR-282) use maven-plugin-tools' java 5 annotations
[ https://jira.codehaus.org/browse/MWAR-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=302325#comment-302325 ] Robert Scholte commented on MWAR-282: - I already noticed a Jenkins failure this morning, it's already fixed. Thanks for mentioning. use maven-plugin-tools' java 5 annotations -- Key: MWAR-282 URL: https://jira.codehaus.org/browse/MWAR-282 Project: Maven 2.x WAR Plugin Issue Type: Task Affects Versions: 2.1.1 Reporter: Tony Chemit Assignee: Robert Scholte Fix For: 2.2 Attachments: MWAR-282_2.diff, MWAR-282.diff -- 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] (MWAR-282) use maven-plugin-tools' java 5 annotations
[ https://jira.codehaus.org/browse/MWAR-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MWAR-282. --- Resolution: Fixed use maven-plugin-tools' java 5 annotations -- Key: MWAR-282 URL: https://jira.codehaus.org/browse/MWAR-282 Project: Maven 2.x WAR Plugin Issue Type: Task Affects Versions: 2.1.1 Reporter: Tony Chemit Assignee: Robert Scholte Fix For: 2.2 Attachments: MWAR-282_2.diff, MWAR-282.diff -- 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] (MPLUGIN-220) Can not use regex in @Parameter(defaultValue)
[
https://jira.codehaus.org/browse/MPLUGIN-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MPLUGIN-220:
--
Assignee: Robert Scholte
Can not use regex in @Parameter(defaultValue)
-
Key: MPLUGIN-220
URL: https://jira.codehaus.org/browse/MPLUGIN-220
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 3.0
Reporter: Tony Chemit
Assignee: Robert Scholte
When transform a javadoc default value
{code}
default-value=[a-zA-Z]{2,}-\\d+
{code}
to
{code}
defaultValue = [a-zA-Z]{2,}-d+
{code}
I have when building :
{code}
Caused by: com.thoughtworks.qdox.parser.ParseException: Illegal escape
character 'd' @[295,85] in
file:/home/tchemit/projets/apache/maven/plugins/maven-changelog-plugin/src/main/java/org/apache/maven/plugin/changelog/ChangeLogReport.java
at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:1018)
at
com.thoughtworks.qdox.parser.impl.Parser.convertString(Parser.java:1126)
at com.thoughtworks.qdox.parser.impl.Parser.toString(Parser.java:1233)
at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:1800)
at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:999)
at
com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:353)
at
com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:381)
at
com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:377)
at
com.thoughtworks.qdox.JavaDocBuilder$2.visitFile(JavaDocBuilder.java:467)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:43)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.scan(DirectoryScanner.java:52)
at
com.thoughtworks.qdox.JavaDocBuilder.addSourceTree(JavaDocBuilder.java:464)
at
com.thoughtworks.qdox.JavaDocBuilder.addSourceTree(JavaDocBuilder.java:453)
at
org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.discoverClasses(JavaAnnotationsMojoDescriptorExtractor.java:453)
at
org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.discoverClasses(JavaAnnotationsMojoDescriptorExtractor.java:443)
at
org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.discoverClasses(JavaAnnotationsMojoDescriptorExtractor.java:422)
at
org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.scanJavadoc(JavaAnnotationsMojoDescriptorExtractor.java:188)
at
org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.execute(JavaAnnotationsMojoDescriptorExtractor.java:106)
at
org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:108)
at
org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:233)
{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] (MPLUGIN-220) Can not use regex in @Parameter(defaultValue)
[
https://jira.codehaus.org/browse/MPLUGIN-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=302326#comment-302326
]
Robert Scholte commented on MPLUGIN-220:
Another reason for me to finally release the first beta versions of QDox 2.0,
which include this fix.
Can not use regex in @Parameter(defaultValue)
-
Key: MPLUGIN-220
URL: https://jira.codehaus.org/browse/MPLUGIN-220
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 3.0
Reporter: Tony Chemit
Assignee: Robert Scholte
When transform a javadoc default value
{code}
default-value=[a-zA-Z]{2,}-\\d+
{code}
to
{code}
defaultValue = [a-zA-Z]{2,}-d+
{code}
I have when building :
{code}
Caused by: com.thoughtworks.qdox.parser.ParseException: Illegal escape
character 'd' @[295,85] in
file:/home/tchemit/projets/apache/maven/plugins/maven-changelog-plugin/src/main/java/org/apache/maven/plugin/changelog/ChangeLogReport.java
at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:1018)
at
com.thoughtworks.qdox.parser.impl.Parser.convertString(Parser.java:1126)
at com.thoughtworks.qdox.parser.impl.Parser.toString(Parser.java:1233)
at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:1800)
at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:999)
at
com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:353)
at
com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:381)
at
com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:377)
at
com.thoughtworks.qdox.JavaDocBuilder$2.visitFile(JavaDocBuilder.java:467)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:43)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.scan(DirectoryScanner.java:52)
at
com.thoughtworks.qdox.JavaDocBuilder.addSourceTree(JavaDocBuilder.java:464)
at
com.thoughtworks.qdox.JavaDocBuilder.addSourceTree(JavaDocBuilder.java:453)
at
org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.discoverClasses(JavaAnnotationsMojoDescriptorExtractor.java:453)
at
org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.discoverClasses(JavaAnnotationsMojoDescriptorExtractor.java:443)
at
org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.discoverClasses(JavaAnnotationsMojoDescriptorExtractor.java:422)
at
org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.scanJavadoc(JavaAnnotationsMojoDescriptorExtractor.java:188)
at
org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.execute(JavaAnnotationsMojoDescriptorExtractor.java:106)
at
org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:108)
at
org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:233)
{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] (MSKINS-28) Make it possible to center powered by logos in sidebar
[ https://jira.codehaus.org/browse/MSKINS-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=302492#comment-302492 ] Robert Scholte commented on MSKINS-28: -- @Andreas, could you verify if the patch is still required? I've updated the version of bootstrap and I don't see any real difference. Make it possible to center powered by logos in sidebar Key: MSKINS-28 URL: https://jira.codehaus.org/browse/MSKINS-28 Project: Maven Skins Issue Type: Wish Components: Fluido Skin Affects Versions: fluido-1.1 Reporter: Andreas Sewe Assignee: Simone Tripodi Priority: Minor Fix For: fluido-1.2 Attachments: maven-theme.patch, mskins-28-it.patch Left alignment may look OK for badge-like logos like http://maven.apache.org/skins/maven-fluido-skin/images/logos/maven-feather.png, but is quite ugly for other types of logo. -- 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] (MSKINS-30) Validate generated site as XHTML 1.0 Transitional
[ https://jira.codehaus.org/browse/MSKINS-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSKINS-30. Resolution: Fixed Fix Version/s: fluido-1.2.2 Assignee: Robert Scholte * Instead of adding an alt-element to the banner, I've removed it so the site inherits the Maven banner from the parent. * I've checked all style-tags, should all include a type now. * I'm having some problems with the footer-fix, especially with the adjustment to the bootstrap.css, because such adjustment will be lost when updating to the next version. I assume it's not a big issue, otherwise I'd expect bootstrap to come with some other solution. Thanks for the patch. Validate generated site as XHTML 1.0 Transitional - Key: MSKINS-30 URL: https://jira.codehaus.org/browse/MSKINS-30 Project: Maven Skins Issue Type: Improvement Components: Fluido Skin Affects Versions: fluido-1.1 Reporter: Bruno P. Kinoshita Assignee: Robert Scholte Priority: Trivial Fix For: fluido-1.2.2 Attachments: MSKINS-30.patch, patch1 The W3C validator for HTML complains about few issues in the site generated by Maven Fluido Skin. Attached you can find a patch that: - includes alt element in the banner image - includes type attribute in style element - replaces footer element (HTML5 only) by a class with class footer - required CSS changes to maintain the same UI -- 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] (MSKINS-28) Make it possible to center powered by logos in sidebar
[ https://jira.codehaus.org/browse/MSKINS-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSKINS-28. Resolution: Fixed Fix Version/s: (was: fluido-1.2) fluido-1.2.2 Assignee: Robert Scholte (was: Simone Tripodi) Fixed in [r1356876|http://svn.apache.org/viewvc?rev=1356876view=rev] I don't see the issue with the large logo's. I can imagine that logo's next to eachother might look odd, it just depends on the sizes. But having them under eachother seems like a save solution. Thanks for the patch! Make it possible to center powered by logos in sidebar Key: MSKINS-28 URL: https://jira.codehaus.org/browse/MSKINS-28 Project: Maven Skins Issue Type: Wish Components: Fluido Skin Affects Versions: fluido-1.1 Reporter: Andreas Sewe Assignee: Robert Scholte Priority: Minor Fix For: fluido-1.2.2 Attachments: maven-theme.patch, mskins-28-it.patch Left alignment may look OK for badge-like logos like http://maven.apache.org/skins/maven-fluido-skin/images/logos/maven-feather.png, but is quite ugly for other types of logo. -- 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] (MSKINS-28) Make it possible to center powered by logos in sidebar
[ https://jira.codehaus.org/browse/MSKINS-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=302629#comment-302629 ] Robert Scholte edited comment on MSKINS-28 at 7/3/12 2:51 PM: -- Fixed in [r1356876|http://svn.apache.org/viewvc?rev=1356876view=rev] I don't see the issue with the large logo's. I can imagine that logo's next to eachother might look odd, it just depends on the sizes. But having them under eachother seems like a safe solution. Thanks for the patch! was (Author: rfscholte): Fixed in [r1356876|http://svn.apache.org/viewvc?rev=1356876view=rev] I don't see the issue with the large logo's. I can imagine that logo's next to eachother might look odd, it just depends on the sizes. But having them under eachother seems like a save solution. Thanks for the patch! Make it possible to center powered by logos in sidebar Key: MSKINS-28 URL: https://jira.codehaus.org/browse/MSKINS-28 Project: Maven Skins Issue Type: Wish Components: Fluido Skin Affects Versions: fluido-1.1 Reporter: Andreas Sewe Assignee: Robert Scholte Priority: Minor Fix For: fluido-1.2.2 Attachments: maven-theme.patch, mskins-28-it.patch Left alignment may look OK for badge-like logos like http://maven.apache.org/skins/maven-fluido-skin/images/logos/maven-feather.png, but is quite ugly for other types of logo. -- 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-659) gitexe SCM: Configurability of SCM info method
[ https://jira.codehaus.org/browse/SCM-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated SCM-659: --- Priority: Minor (was: Major) gitexe SCM: Configurability of SCM info method --- Key: SCM-659 URL: https://jira.codehaus.org/browse/SCM-659 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-git Affects Versions: 1.6 Reporter: Paul Hicks Priority: Minor I need to use the output of git describe with the buildnumber plugin. The newest versions of gitexe scm are using git rev-parse --verify HEAD which is a sensible choice, but won't work for me. Is there a way to configure how the info method works? I can't find a definition of the API. I'd be happy to develop this and submit a patch. I just need to know how individual methods in the SCM plugin are configured. I'm not having any luck with http://maven.apache.org/scm/maven-scm-api/ -- 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-357) use plugins annotations
[ https://jira.codehaus.org/browse/MDEP-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MDEP-357: Issue Type: Improvement (was: Bug) use plugins annotations --- Key: MDEP-357 URL: https://jira.codehaus.org/browse/MDEP-357 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 2.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] (SUREFIRE-881) use plugins annotations
[ https://jira.codehaus.org/browse/SUREFIRE-881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated SUREFIRE-881: Issue Type: Improvement (was: Bug) use plugins annotations --- Key: SUREFIRE-881 URL: https://jira.codehaus.org/browse/SUREFIRE-881 Project: Maven Surefire Issue Type: Improvement Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 2.13 -- 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
