Same for SVN. The plugin should restore the original entries in the trunk (HEAD revision) again.

I posted a question regarding this on the maven users mailing list. At least now I know it appears to be a bug and not my POM.
But I get the problem when using release:perform as well. Do I need to create another issue for this (quite new to JIRA/reporting)?

Another slight difference is that my property is for the SCM username and password - ${cvs-user} and ${cvs-pass}. After a release:perform both of these properties are replaced with the ones from the settings.xml. I have tried removing the properties from the POM and specifiying them with \ -Dusername and -Dpassword. Doing this also reasults in the SCM path being altered and the login details added. Both the exported POM and the original POM are incorrectly altered.

<scm>
  <connection>scm:cvs:pserver:${cvs-user}:${cvs-pass}@10.0.0.3:/usr/share/cvs/cvsroot:MyProjectName</connection>
  <developerConnection>scm:cvs:pserver:${cvs-user}:${cvs-pass}@10.0.0.3:/usr/share/cvs/cvsroot:MyProjectName</developerConnection>
</scm>

turns to

<scm>
  <connection>scm:cvs:pserver:joebloggs:p4ssw0rd@10.0.0.3:/usr/share/cvs/cvsroot:MyProjectName</connection>
  <developerConnection>scm:cvs:pserver:joebloggs:p4ssw0rd@10.0.0.3:/usr/share/cvs/cvsroot:MyProjectName</developerConnection>
</scm>

after the release:perform is called.

I experienced this problem but with release:prepare, not release:perform. To the best of my knowledge, release:perform shouldn't be modifying any checked-in code. It simply checks out the configured tag and runs whatever goals it's configured to run (like deploy, deploy-site).

FYI - this seems very related to http://jira.codehaus.org/browse/MRELEASE-114. Someone with edit permission may want to combine this issue, http://jira.codehaus.org/browse/MRELEASE-114 and http://jira.codehaus.org/browse/MRELEASE-16.

I'm attaching a possible fix for this issue to MRELEASE-114. I had meant to post it here (which is why it's named as such), but apparently I have issue keeping track of my firefox tabs. The below notes are identical to my comments on MRELEASE-114.

Some notes:

1. I made the assumption that the only reason we rewrite the scm config is for subversion. This is quite possibly not the case, but it passed all the unit tests and made my CVS scm do what I wanted it to. This is probably not the way it should be implemented, but I don't know enough about the other SCMs to know if the rewrite is a special case or the non-rewrite is a special case.
2. This is a patch from the 2.0-beta-4 tag because the trunk didn't install cleanly on checkout - it may or may not be easily portable to the trunk.

I'm experiencing the same problem but with ${user.name}

where the tagged release value is correct but the transformed version for the next snapshot is incorrect as $[user.name}
has been expanded to be the current users name.

This doesn't look like it is fixed by reading the patch attached to MRELEASE-114.

Already fixed.

wonderful!

Tested on my first release with beta-5 and the scm url is still badly updated.

Stephane - was is the difference between the test cases and your environment?

Just wondering if this was actually fixed for a certain set of cases (and a new issue needs to be opened), or not fixed at all (and so the fix version needs to be changed)

Brett,

It's very similar to the comment of Barrie Treloar. I have a ${maven.username} token in the developerConnection entry and it's replaced by release:prepare.

See this diff

[maven-release-plugin] prepare for next development iteration

Index: pom.xml
===================================================================
RCS file: /data/cvsroot/bar/pom.xml,v
retrieving revision 1.19.4.7
retrieving revision 1.19.4.8
diff -u -d -r1.19.4.7 -r1.19.4.8
--- pom.xml	23 May 2007 13:58:35 -0000	1.19.4.7
+++ pom.xml	23 May 2007 13:58:54 -0000	1.19.4.8
@@ -8,7 +8,7 @@
     </parent>
     <groupId>com.foo.shared.bar</groupId>
     <artifactId>ionic-bar</artifactId>
-    <version>5.5.5</version>
+    <version>5.5.6-SNAPSHOT</version>
     <packaging>jar</packaging>
     <inceptionYear>2007</inceptionYear>
     <name>bar</name>
@@ -296,8 +296,8 @@
 
     <scm>
         <connection>scm:cvs:pserver:anonymous:blablabla@cvsserver:/data/cvsroot:bar</connection>
-        <developerConnection>scm:cvs:pserver:$\{maven.username\}@cvsserver:/data/cvsroot:bar</developerConnection>
+        <developerConnection>scm:cvs:pserver:maven@cvsserver:/data/cvsroot:bar</developerConnection>
         <url>http://intranet/cgi-bin/viewcvs.cgi/bar/</url>
-        <tag>V5_5_5</tag>
+        <tag>RSE341</tag>
   </scm>
 </project>

SCM is CVS of course.

and forget the \ between the { (otherwise the formating is screwed).

I agree. Just saying it is fixed doesn't make it so. We use ${USER} in the developerConnection (CVS) and it's being replaced too. Plugin version is 2.0-beta-6.

I'm still seeing this issue with maven-release-plugin 2.0-beta-7. The pom in the tag is correct, but the final pom in the HEAD has ${user.name} expanded in the <scm> section.

I have attacted a patch for CVS only (it is more a hack than a patch)
File: MRELEASE-128_cvs_hack_RewritePomsForDevelopmentPhase.java.patch.

I think the Method transformScm() in org.apache.maven.shared.release.phase.RewritePomsForDevelopmentPhase must be implements like the Method translateScm() in org.apache.maven.shared.release.phase.RewritePomsForReleasePhase, but my knowledge about scm and maven is not good enough to be sure.

Here's a patch which fixes the problems for pom.xml.next and pom.xml.tag:
MNG-128-maven-release-manager.patch

Branching is not (yet) supported.

It works like this: instead of using scm.getConnection() and scm.getDeveloperConnection() (which both contain the resolved variables), it uses the original text contained in pom.xml (using the XML element).

HOWEVER ... the tests for RewritePomsForDevelopmentPhase fail. I don't know exactly what's going on, but ... hmm, could the tests be wrong? (This is a silly assumption, I know, but ... well, I just don't know.)

Still, after patching you can install maven-release-manager with

mvn -Dmaven.test.skip=true clean install

and see if it works for you, too.

Emmanuel,

I believe this is still broken in RewritePomsForDevelopmentPhase.transformScm(). The RewritePomsForReleasePhase.transformScm() works fine (note releaseConfiguration.mapOriginalScmInfo( projectId, project.getScm() ) , but values after string substitution are still used when prepping for the next development phase.

Here are changes on my pom that were committed to cvs over the prepare-perform cycle (replaced some parts with <...>)

Note the ${scm.username} is replaced with starver

<scm>
<connection>scm:cvs:ext:${scm.username}@<...></connection>
<developerConnection>scm:cvs:ext:${scm.username}@<...></developerConnection>
<url>http://vntwb1da.it.foo.net/cvsweb/cvsweb.cgi/<...>/oss-ticket-api/</url>
</scm>

<scm>
<connection>scm:cvs:ext:${scm.username}@<...></connection>
<developerConnection>scm:cvs:ext:${scm.username}@<...></developerConnection>
<url>http://vntwb1da.it.foo.net/cvsweb/cvsweb.cgi/<...>/oss-ticket-api/</url>
<tag>oss-ticket-api-1_0_29</tag>
</scm>

<scm>
<connection>scm:cvs:ext:starver@<...></connection>
<developerConnection>scm:cvs:ext:starver@<...></developerConnection>
<url>http://vntwb1da.it.foo.net/cvsweb/cvsweb.cgi/<...>/oss-ticket-api/</url>
</scm>

Hi,
We are still experiencing this problem with the following configuration:
$ mvn --version
Maven version: 2.0.9
Java version: 1.6.0_07
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
org.apache.maven.plugins:maven-release-plugin:maven-plugin:2.0-beta-7:runtime

The POM files are changed after having called
mvn release:prepare
(not even a release:perform).

scm part in parent POM before release:prepare:
<scm>
<url>http://cvs.server.xx/cvs/test/continuous_integration/${project.artifactId}</url>
<developerConnection>${cvs.connection.test}continuous_integration/${project.artifactId}</developerConnection>
</scm>

scm part in parent POM AFTER release:prepare (properties have been replaced):
<scm>
<url>http://cvs.server.xx/cvs/test/continuous_integration/ipi-multimodule</url>
<developerConnection>scm:cvs|pserver|build_user@cvs.server.xx|/var/cvs/test|continuous_integration/ipi-multimodule</developerConnection>
</scm>

scm part in child POM before release:prepare:
<scm>
<url>${parent.scm.url}/${project.artifactId}</url>
</scm>

scm part in child POM AFTER release:prepare (properties have been replaced and a new line has been inserted; inheritance is broken!):
<scm>
<url>${parent.scm.url}/ipi-multimodule-a</url>
<developerConnection>scm:cvs|pserver|build_user@cvs.server.xx|/var/cvs/test|continuous_integration/ipi-multimodule-a/ipi-multimodule-a</developerConnection>
</scm>

Please see
http://jira.codehaus.org/browse/MRELEASE-389?focusedCommentId=156709&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_156709

As we are currently moving some projects from cvs to subversion I recognized that the patch
MRELEASE-128_cvs_hack_RewritePomsForDevelopmentPhase.java.patch

is only valid for CVS. When using svn the patch may not be used as otherwise the poms left in the trunk/branch will then include the tagname. So I did put around two ifs in RewritePomsForDevelopmentPhase, checking if it is scm:cvs:

                     if ( scm != null )
                     {
                    	String connection = scm.getConnection();
                    	String developerConnection = scm.getDeveloperConnection();
                    	if ((connection != null) && (connection.startsWith("scm:cvs:"))) {
	                    	//MRELEASE-128
                    		String oldConnection = connection;
	                        connection = ( scmRoot.getChildText("connection", namespace) != null )
									? scmRoot.getChildText("connection", namespace)
									: scm.getConnection();
				getLogger().info("applying Patch MRELEASE-128 to connection, replacing " + oldConnection + " with " + connection);
                    	}
                    	if ((developerConnection != null) && (developerConnection.startsWith("scm:cvs:"))) {
	                    	//MRELEASE-128
                    		String oldConnection = developerConnection;
				developerConnection = ( scmRoot.getChildText("developerConnection", namespace) != null )
									? scmRoot.getChildText("developerConnection", namespace)
									: scm.getDeveloperConnection();
				getLogger().info("applying Patch MRELEASE-128 to developerConnection, replacing " + oldConnection + " with " + connection);
                    	}
                        rewriteElement( "connection", connection, scmRoot, namespace );
                        rewriteElement( "developerConnection", developerConnection, scmRoot, namespace );
                        rewriteElement( "url", scm.getUrl(), scmRoot, namespace );
                        rewriteElement( "tag", translator.resolveTag( scm.getTag() ), scmRoot, namespace );

(sorry - I am currently not able to create a patch-file for this as we have reversioned the source in our corporate system and it would not be applyable to the 'official' branch). It should be (after applying the patch mentioned above in src/main/java/org/apache/maven/shared/release/phase/RewritePomsForDevelopmentPhase.java
around line 72

now it seems to work with both cvs and svn.

When I am at home I will try to apply this to a 'fresh' checkout from the branch and create a real patch-file

Edit: formatting

Wow, this bug is THREE AND A HALF YEARS OLD and nobody has been able to fix it?
We're supposed to use Maven, but after all this time it's still not able to create a release without messing up the POMs?

+1 for fixing this bug.

The ticket says "Fix Version/s: 2.0.1". Is it now really fixed in 2.0.1?

Are you planning to release a fixed version soon? If it's fixed and tagged in svn I would not bother to build it myself...