Maven 2.x Release Plugin

SCM properties being replaced during release:perform

Details

  • Type: Bug Bug
  • Status: Reopened Reopened
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: 2.3
  • Component/s: prepare
  • Labels:
  • Environment:
    Windows XP client, Linux repo, CVS, Maven 2.0.4
  • Testcase included:
    yes
  • Patch Submitted:
    Yes
  • Number of attachments :
    5

Description

The <scm> section of a pom in CVS for a pom archetype project looks like this prior to executing release:prepare :

<scm>
<connection>${base.cvs.url}:commons-maven/uber-pom</connection>
<developerConnection>${base.cvs.url}:commons-maven/uber-pom</developerConnection>
<url>${base.viewcvs.url}/commons-maven/uber-pom</url>
</scm>

Then after executing release:prepare, the pom in CVS looks like this (new <tag> tag is only difference):

<scm>
<connection>${base.cvs.url}:commons-maven/uber-pom</connection>
<developerConnection>${base.cvs.url}:commons-maven/uber-pom</developerConnection>
<url>${base.viewcvs.url}/commons-maven/uber-pom</url>
<tag>R-1_7</tag>
</scm>

Then after executing release:perform, the pom looks like this in CVS:

<scm>
<connection>scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom</connection>
<developerConnection>scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom</developerConnection>
<url>http://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom</url>
</scm>

Notice that the properties that were there for the base URLs for CVS and ViewCVS have been replaced with literal values.

No other properties in the POM are being replaced

  1. after-release-perform-pom.xml
    06/Jun/06 9:37 AM
    4 kB
    Craig Dickson
  2. after-release-prepre-pom.xml
    06/Jun/06 9:37 AM
    3 kB
    Craig Dickson
  3. MNG-128-maven-release-manager.patch
    05/Apr/08 2:52 PM
    3 kB
    Torben S. Giesselmann
  4. MRELEASE-128_cvs_hack_RewritePomsForDevelopmentPhase.java.patch
    05/Feb/08 2:57 AM
    1 kB
    Sascha Groß
  5. original-pom.xml
    06/Jun/06 9:37 AM
    3 kB
    Craig Dickson

Issue Links

Activity

Hide
Joerg Schaible added a comment -

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

Show
Joerg Schaible added a comment - Same for SVN. The plugin should restore the original entries in the trunk (HEAD revision) again.
Hide
Martin Gilday added a comment -

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.

Show
Martin Gilday added a comment - 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.
Hide
Eric Bernstein added a comment -

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.

Show
Eric Bernstein added a comment - 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.
Hide
Eric Bernstein added a comment -

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.

Show
Eric Bernstein added a comment - 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.
Hide
Barrie Treloar added a comment -

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



<developerConnection>
scm:cvs:pserver:${user.name}@CVS_HOST:/cvs/CVS_ROOT:PROJECT_DIR
</developerConnection>


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.

Show
Barrie Treloar added a comment - I'm experiencing the same problem but with ${user.name}

<developerConnection> scm:cvs:pserver:${user.name}@CVS_HOST:/cvs/CVS_ROOT:PROJECT_DIR </developerConnection>

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.
Hide
Emmanuel Venisse added a comment -

Already fixed.

Show
Emmanuel Venisse added a comment - Already fixed.
Hide
Stephane Nicoll added a comment -

wonderful!

Show
Stephane Nicoll added a comment - wonderful!
Hide
Stephane Nicoll added a comment -

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

Show
Stephane Nicoll added a comment - Tested on my first release with beta-5 and the scm url is still badly updated.
Hide
Brett Porter added a comment -

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)

Show
Brett Porter added a comment - 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)
Hide
Stephane Nicoll added a comment - - edited

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.

Show
Stephane Nicoll added a comment - - edited 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.
Hide
Stephane Nicoll added a comment -

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

Show
Stephane Nicoll added a comment - and forget the \ between the { (otherwise the formating is screwed).
Hide
Stefan Seidel added a comment -

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.

Show
Stefan Seidel added a comment - 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.
Hide
Vadim Strizhevsky added a comment - - edited

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.

Show
Vadim Strizhevsky added a comment - - edited 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.
Hide
Sascha Groß added a comment -

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.

Show
Sascha Groß added a comment - 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.
Hide
Torben S. Giesselmann added a comment - - edited

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.

Show
Torben S. Giesselmann added a comment - - edited 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.
Hide
Steve Tarver added a comment - - edited

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>

Show
Steve Tarver added a comment - - edited 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>
Hide
jcrouvi added a comment -

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>

Show
jcrouvi added a comment - 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>
Hide
Michael Wenig added a comment - - edited

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

Show
Michael Wenig added a comment - - edited 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
Hide
Havard Bjastad added a comment -

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?

Show
Havard Bjastad added a comment - 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?
Hide
Torben Knerr added a comment -

+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...

Show
Torben Knerr added a comment - +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...
Hide
Russell added a comment -

I'm having this problem, yet I notice this ticket has been open since June 2006

Is anyone looking at this? Is it fixed in 2.0.1? If so, will 2.0.1 be released soon?

Show
Russell added a comment - I'm having this problem, yet I notice this ticket has been open since June 2006 Is anyone looking at this? Is it fixed in 2.0.1? If so, will 2.0.1 be released soon?
Hide
Sylvain Marié added a comment -

+1. But for us I don't think the property is enough ; indeed we would like children pom to have their full path be configured correctly. If a NON-AGGREGATOR parent project is configured as follows:

<!-- properties -->
<svnserver.prop>svn.com<svnserver.prop>
<path.prop>foo</path.prop>

<scm>
<connection>scm:svn:http://${svnserver.prop}/${path.prop}/${artifactId}/trunk/</developerConnection>
<developerConnection>scm:svn:http://${svnserver.prop}/${path.prop}/${artifactId}/trunk/</developerConnection>
<url>http://${svnserver.prop}/view/${path.prop}/${artifactId}/trunk/</url>
<scm>

then if releasing version 1, its release pom in the svn TAG will be (even keeping the properties)

<!-- same properties -->

<scm>
<connection>scm:svn:http://${svnserver.prop}/${path.prop}/${artifactId}/tags/parent-pom-1/</developerConnection>
<developerConnection>scm:svn:http://${svnserver.prop}/${path.prop}/${artifactId}/tags/parent-pom-1/</developerConnection>
<url>http://${svnserver.prop}/view/${path.prop}/${artifactId}/tags/parent-pom-1/</url>
<scm>

I would like a child project also sitting on the same server to be able to inherit most of the configuration.
What should I do ? Well even properties won't help it to inherit from the url below, because its parent is a TAG.
So I have to rewrite all the scm section :

<scm>
<connection>scm:svn:http://${svnserver.prop}/${path.prop}/${artifactId}/trunk/</developerConnection>
<developerConnection>scm:svn:http://${svnserver.prop}/${path.prop}/${artifactId}/trunk/</developerConnection>
<url>http://${svnserver.prop}/view/${path.prop}/${artifactId}/trunk/</url>
<scm>

A major breakthrough would be to be able to set a RELATIVE SCM URL wrt the parent's trunk. This would really ease the process, as a child would now write

<relative>../${artifactId}<relative>

Note that this url needs to be understood by maven SVN scm plugin - so I guess this is more a Maven 3.x feature and not in scope of maven-release plugin...

regards

Sylvain

Show
Sylvain Marié added a comment - +1. But for us I don't think the property is enough ; indeed we would like children pom to have their full path be configured correctly. If a NON-AGGREGATOR parent project is configured as follows: <!-- properties --> <svnserver.prop>svn.com<svnserver.prop> <path.prop>foo</path.prop> <scm> <connection>scm:svn:http://${svnserver.prop}/${path.prop}/${artifactId}/trunk/</developerConnection> <developerConnection>scm:svn:http://${svnserver.prop}/${path.prop}/${artifactId}/trunk/</developerConnection> <url>http://${svnserver.prop}/view/${path.prop}/${artifactId}/trunk/</url> <scm> then if releasing version 1, its release pom in the svn TAG will be (even keeping the properties) <!-- same properties --> <scm> <connection>scm:svn:http://${svnserver.prop}/${path.prop}/${artifactId}/tags/parent-pom-1/</developerConnection> <developerConnection>scm:svn:http://${svnserver.prop}/${path.prop}/${artifactId}/tags/parent-pom-1/</developerConnection> <url>http://${svnserver.prop}/view/${path.prop}/${artifactId}/tags/parent-pom-1/</url> <scm> I would like a child project also sitting on the same server to be able to inherit most of the configuration. What should I do ? Well even properties won't help it to inherit from the url below, because its parent is a TAG. So I have to rewrite all the scm section : <scm> <connection>scm:svn:http://${svnserver.prop}/${path.prop}/${artifactId}/trunk/</developerConnection> <developerConnection>scm:svn:http://${svnserver.prop}/${path.prop}/${artifactId}/trunk/</developerConnection> <url>http://${svnserver.prop}/view/${path.prop}/${artifactId}/trunk/</url> <scm> A major breakthrough would be to be able to set a RELATIVE SCM URL wrt the parent's trunk. This would really ease the process, as a child would now write <relative>../${artifactId}<relative> Note that this url needs to be understood by maven SVN scm plugin - so I guess this is more a Maven 3.x feature and not in scope of maven-release plugin... regards Sylvain
Hide
Lars Fischer added a comment -

Hello,
is there a plan to fix this issue?

Regards,
Lars

Show
Lars Fischer added a comment - Hello, is there a plan to fix this issue? Regards, Lars
Hide
Jan Ruzicka added a comment -

Is there anything preventing the attached patch to be committed?

Show
Jan Ruzicka added a comment - Is there anything preventing the attached patch to be committed?
Hide
Michael Glauche added a comment - - edited

I think i found some workaround at least for the username/password issue:

First, remove the parameters from the SCM url like this:

<scm>
  <connection>scm:cvs:pserver:cvsserver:/home/cvs/repository/test:test</connection>
</scm>

This way only works if you supply the release plugin with an username/password, like -Dusername=...

Fortunately you can set it in the build section like this:

<build>
  	<plugins>
	  	<plugin>
  			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-release-plugin</artifactId>
			<configuration>
				<username>${maven.scm.username}</username>
				<password>${maven.scm.password}</password>
			</configuration>
  		</plugin>
  	</plugins>
</build>

As the substitution only is broken inside the scm tag, this should work.

You just need to define maven.scm.username and password in your local settings and things start to look better

Show
Michael Glauche added a comment - - edited I think i found some workaround at least for the username/password issue: First, remove the parameters from the SCM url like this:
<scm>
  <connection>scm:cvs:pserver:cvsserver:/home/cvs/repository/test:test</connection>
</scm>
This way only works if you supply the release plugin with an username/password, like -Dusername=... Fortunately you can set it in the build section like this:
<build>
  	<plugins>
	  	<plugin>
  			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-release-plugin</artifactId>
			<configuration>
				<username>${maven.scm.username}</username>
				<password>${maven.scm.password}</password>
			</configuration>
  		</plugin>
  	</plugins>
</build>
As the substitution only is broken inside the scm tag, this should work. You just need to define maven.scm.username and password in your local settings and things start to look better
Hide
Brett Porter added a comment -

Committed a fix in r1002124.

I think Torben's patch would have worked, but I instead used the project.getOriginalModel() for transforming the SCM elements, since that also retrieves the ones set by Maven before applying interpolation.

Show
Brett Porter added a comment - Committed a fix in r1002124. I think Torben's patch would have worked, but I instead used the project.getOriginalModel() for transforming the SCM elements, since that also retrieves the ones set by Maven before applying interpolation.
Hide
Lars Fischer added a comment -

Hello,

I tried to use version 2.1 with this configuration:

<scm>
<connection>scm:svn:svn://${scm.host}/commons/trunk/xyz</connection>
<developerConnection>scm:svn:svn://${scm.host}/commons/trunk/xyz</developerConnection>
<url>http://${scm.host}/cgi-bin/viewvc.cgi/Commons</url>
</scm>

After releasing, the ${scm.host} in the new snapshot-pom was replaced by the ${scm.host}-value. Is there a way to keep the "${scm.host}"?

Show
Lars Fischer added a comment - Hello, I tried to use version 2.1 with this configuration: <scm> <connection>scm:svn:svn://${scm.host}/commons/trunk/xyz</connection> <developerConnection>scm:svn:svn://${scm.host}/commons/trunk/xyz</developerConnection> <url>http://${scm.host}/cgi-bin/viewvc.cgi/Commons</url> </scm> After releasing, the ${scm.host} in the new snapshot-pom was replaced by the ${scm.host}-value. Is there a way to keep the "${scm.host}"?
Hide
Markku Saarela added a comment -

I confirms previous comment. With Maven 3.0 and and plugin version 2.1 I still get in scm element properties replaced with their actual values.

Show
Markku Saarela added a comment - I confirms previous comment. With Maven 3.0 and and plugin version 2.1 I still get in scm element properties replaced with their actual values.
Hide
Markku Saarela added a comment -

Also Maven 2.2.1 with 2.1 version doesn't work correctly.

Show
Markku Saarela added a comment - Also Maven 2.2.1 with 2.1 version doesn't work correctly.
Hide
werner mueller added a comment -

same here, maven 2.2.1, release-plugin 2.1 the scm properties are replaced.

<scm>
    <connection>scm:svn:${svn.url}/Projekt</connection>
    <developerConnection>scm:svn:${svn.url}/Projekt</developerConnection>
    <url>${svn.url}/Projekt</url>
  </scm>
Show
werner mueller added a comment - same here, maven 2.2.1, release-plugin 2.1 the scm properties are replaced.
<scm>
    <connection>scm:svn:${svn.url}/Projekt</connection>
    <developerConnection>scm:svn:${svn.url}/Projekt</developerConnection>
    <url>${svn.url}/Projekt</url>
  </scm>
Hide
Frédéric Camblor added a comment -

+1
How could we "re-open" the issue ?
Looks like I don't have sufficient rights to do this.

Show
Frédéric Camblor added a comment - +1 How could we "re-open" the issue ? Looks like I don't have sufficient rights to do this.
Hide
Stanley Brubaker added a comment - - edited

Maven 2.2.1, maven-release-plugin 2.1.

I've put the following in our super pom to give developers a pattern for all projects without having to configure scm in every child pom. We also have the svn host to be set in the settings.xml file:

<scm>
    <connection>scm:svn:http://${scm.host}/svn/${project.artifactId}/trunk/</connection>
    <developerConnection>scm:svn:http://${scm.host}/svn/${project.artifactId}/trunk/</developerConnection>
    <url>http://${scm.host}/viewvc/${project.artifactId}/trunk/</url>
</scm>

This works fine during development. When we run release:prepare, the checked-in tag pom.xml looks like this:

<scm>
    <connection>scm:svn:http://${scm.host}/svn/${project.artifactId}/tags/our-super-pom-1.0</connection>
    <developerConnection>scm:svn:http://${scm.host}/svn/${project.artifactId}/tags/our-super-pom-1.0</developerConnection>
    <url>http://${scm.host}/viewvc/${project.artifactId}/tags/our-super-pom-1.0</url>
</scm>

This is incorrect. If I expect to point child poms to the released parent, the scm section should remain the same as it was.

Also, the new snapshot pom.xml is changed to this:

<scm>
    <connection>scm:svn:http://host.company.net/svn/our-super-pom/trunk/</connection>
    <developerConnection>scm:svn:http://host.company.net/svn/our-super-pom/trunk/</developerConnection>
    <url>http://host.company.net/viewvc/our-super-pom/trunk/</url>
</scm>

This is incorrect. The next version of the pom.xml should be left alone, except for the version changing to 1.1-SNAPSHOT. Since we release our parent poms like everything else, there is no reason to modify anything besides the versions during the release process. Can we not have a property the disables substitutions altogether?

Show
Stanley Brubaker added a comment - - edited Maven 2.2.1, maven-release-plugin 2.1. I've put the following in our super pom to give developers a pattern for all projects without having to configure scm in every child pom. We also have the svn host to be set in the settings.xml file:
<scm>
    <connection>scm:svn:http://${scm.host}/svn/${project.artifactId}/trunk/</connection>
    <developerConnection>scm:svn:http://${scm.host}/svn/${project.artifactId}/trunk/</developerConnection>
    <url>http://${scm.host}/viewvc/${project.artifactId}/trunk/</url>
</scm>
This works fine during development. When we run release:prepare, the checked-in tag pom.xml looks like this:
<scm>
    <connection>scm:svn:http://${scm.host}/svn/${project.artifactId}/tags/our-super-pom-1.0</connection>
    <developerConnection>scm:svn:http://${scm.host}/svn/${project.artifactId}/tags/our-super-pom-1.0</developerConnection>
    <url>http://${scm.host}/viewvc/${project.artifactId}/tags/our-super-pom-1.0</url>
</scm>
This is incorrect. If I expect to point child poms to the released parent, the scm section should remain the same as it was. Also, the new snapshot pom.xml is changed to this:
<scm>
    <connection>scm:svn:http://host.company.net/svn/our-super-pom/trunk/</connection>
    <developerConnection>scm:svn:http://host.company.net/svn/our-super-pom/trunk/</developerConnection>
    <url>http://host.company.net/viewvc/our-super-pom/trunk/</url>
</scm>
This is incorrect. The next version of the pom.xml should be left alone, except for the version changing to 1.1-SNAPSHOT. Since we release our parent poms like everything else, there is no reason to modify anything besides the versions during the release process. Can we not have a property the disables substitutions altogether?
Hide
Anthony Whitford added a comment -

Has this issue really been open for more than 4 years?
This is a critical one for me; I am unable to adopt the latest release plugin until this is resolved.
I think this also impairs my progress towards Maven 3.
I'd really appreciate this being resolved! Thanks!

Show
Anthony Whitford added a comment - Has this issue really been open for more than 4 years? This is a critical one for me; I am unable to adopt the latest release plugin until this is resolved. I think this also impairs my progress towards Maven 3. I'd really appreciate this being resolved! Thanks!
Hide
Barrie Treloar added a comment -

Anthony, it's open source. Feel free to roll up the sleeves and provide some help to get it resolved.

Show
Barrie Treloar added a comment - Anthony, it's open source. Feel free to roll up the sleeves and provide some help to get it resolved.
Hide
werner mueller added a comment -

well a lot of plugins have this issue as well. The properties in its original form cannot be read via the plugin api (as far as i know). You can only retrieve them in the replaced way. So any plugin that rewrites the pom runs into this.

from what i know from the plugin it parses the pom.xml manually and replaces the strings 'by hand'. Which in my eyes is more tricky than one would think (depends on what part you replace with properties, your project layout, if you tag or branch or release, ...?)

But how can this be mission critical? It never 'worked' or has been this way. The release plugin (using svn in my case) needs these three lines in the scm, tabBase and branchBase are constant. In my eyes this features serves some readability in the pom and allows infrastructure changes without touching the pom files. If you do that a lot you're doomed anyway

Show
werner mueller added a comment - well a lot of plugins have this issue as well. The properties in its original form cannot be read via the plugin api (as far as i know). You can only retrieve them in the replaced way. So any plugin that rewrites the pom runs into this. from what i know from the plugin it parses the pom.xml manually and replaces the strings 'by hand'. Which in my eyes is more tricky than one would think (depends on what part you replace with properties, your project layout, if you tag or branch or release, ...?) But how can this be mission critical? It never 'worked' or has been this way. The release plugin (using svn in my case) needs these three lines in the scm, tabBase and branchBase are constant. In my eyes this features serves some readability in the pom and allows infrastructure changes without touching the pom files. If you do that a lot you're doomed anyway
Hide
Michael Glauche added a comment -

For CVS it is kind of mission critical, you'll need to specify a scm username in the connection string, or otherwise the site plugin will crash. Hardcoding a name a la "svn@" does not work with cvs, so you really need a variable there if you have more than one user ...

Show
Michael Glauche added a comment - For CVS it is kind of mission critical, you'll need to specify a scm username in the connection string, or otherwise the site plugin will crash. Hardcoding a name a la "svn@" does not work with cvs, so you really need a variable there if you have more than one user ...
Hide
Stephen Connolly added a comment -

Pushing back to 2.3 as this is a large scope of work, and there are some issues that we want to push 2.2 out for.

Show
Stephen Connolly added a comment - Pushing back to 2.3 as this is a large scope of work, and there are some issues that we want to push 2.2 out for.
Hide
rumi added a comment -

The same for git provider. SCM properties are not changed, project.scm.tag (git version) is not added/updated in particular.
May it may be caused by lack of GitScmTranslator ?

Show
rumi added a comment - The same for git provider. SCM properties are not changed, project.scm.tag (git version) is not added/updated in particular. May it may be caused by lack of GitScmTranslator ?

People

Vote (73)
Watch (59)

Dates

  • Created:
    Updated: