Maven 2.x Release Plugin

${project.artifactId} was replaced with it's value during release:perform

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.0-beta-5
  • Component/s: None
  • Labels:
    None
  • Environment:
    Windows XP, Java 1.4.2
  • Number of attachments :
    1

Description

In release:perform, the variable ${project.artifactId} was replaced with it's value in the connection and developerConnection tags in the pom. This did NOT happen in other place in the pom!

Before release:
<connection>scm:cvs:pserver:cvsanon@cvs.foo.com:/bar:${project.artifactId}</connection>

After release:
<connection>scm:cvs:pserver:cvsanon@cvs.foo.com:/bar:master-pom</connection>

BTW: The issue http://jira.codehaus.org/browse/MRELEASE-16 may be
related to the above problem.

Issue Links

This issue relates to:
MRELEASE-16 release-pom is changed too much Major Closed
This issue is related to:
MRELEASE-128 SCM properties being replaced during release:perform Critical Reopened

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Paul Spencer added a comment -

Fogot to set affected version to Release plugin 2.0-beta-4

Show
Paul Spencer added a comment - Fogot to set affected version to Release plugin 2.0-beta-4
Hide
Permalink
Paul Spencer added a comment -

The <url> tag inside the <scm> tag is also affected by this bug.

Show
Paul Spencer added a comment - The <url> tag inside the <scm> tag is also affected by this bug.
Hide
Permalink
Richard van der Hoff added a comment -

Yes it is, and it's very annoying.

Sounds like a duplicate of MRELEASE-16 to me.

Show
Richard van der Hoff added a comment - Yes it is, and it's very annoying. Sounds like a duplicate of MRELEASE-16 to me.
Hide
Permalink
Eric Bernstein added a comment -

I'm attaching a possible fix for this issue.

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

My bad, I named the patch for MRELEASE-128, but published it to MRELEASE-114. Sorry about that. I do believe MRELEASE-128 and MRELEASE-114 are the same issue though, and I can't remove the attachement, so it'll stay. Hope no one minds too much. I'll comment on MRELEASE-114 and point that issue over here.

Show
Eric Bernstein added a comment - My bad, I named the patch for MRELEASE-128, but published it to MRELEASE-114. Sorry about that. I do believe MRELEASE-128 and MRELEASE-114 are the same issue though, and I can't remove the attachement, so it'll stay. Hope no one minds too much. I'll comment on MRELEASE-114 and point that issue over here.
Hide
Permalink
Jurgen Lust added a comment -

I checked out the 2.0-beta-4 tag of the maven-release-plugin and applied the patch supplied here, but the problem remains: ${user.name} and ${artifactId} are being replaced in the scm section and committed to svn...

Show
Jurgen Lust added a comment - I checked out the 2.0-beta-4 tag of the maven-release-plugin and applied the patch supplied here, but the problem remains: ${user.name} and ${artifactId} are being replaced in the scm section and committed to svn...
Hide
Permalink
Eric Bernstein added a comment -

Yes, Jurgen, that's where my patch falls short (see point 1 on my notes above). I knew SVN needed some form of rewrite (for tagging, etc...) and CVS (and others) did not. Not being very familiar with SVN, I kept the SVN functionality the same and exempted the other SCMs so that I would, at worst, do no harm.

If you have a better understanding of SVN, I imagine the patch could be improved by manipulating the URLs as they should be using the base URLs rather than the evaluated URLs as I believe they are today.

Show
Eric Bernstein added a comment - Yes, Jurgen, that's where my patch falls short (see point 1 on my notes above). I knew SVN needed some form of rewrite (for tagging, etc...) and CVS (and others) did not. Not being very familiar with SVN, I kept the SVN functionality the same and exempted the other SCMs so that I would, at worst, do no harm. If you have a better understanding of SVN, I imagine the patch could be improved by manipulating the URLs as they should be using the base URLs rather than the evaluated URLs as I believe they are today.
Hide
Permalink
Ian Springer added a comment -

I had ${maven.username} is the value of scm.developerConnection, and it was resolved and replaced in both the "prepare release X.Y.Z" POM and the "prepare for next development iteration" POM. I think this is incorrect behavior in both cases, but particularly undesirable in the latter case... Will this be fixed in the next release?

Show
Ian Springer added a comment - I had ${maven.username} is the value of scm.developerConnection, and it was resolved and replaced in both the "prepare release X.Y.Z" POM and the "prepare for next development iteration" POM. I think this is incorrect behavior in both cases, but particularly undesirable in the latter case... Will this be fixed in the next release?
Hide
Permalink
Emmanuel Venisse added a comment -

Already fixed

Show
Emmanuel Venisse added a comment - Already fixed
Hide
Permalink
Havard Bjastad added a comment -

Emmanuel, you're saying "Already fixed", but we're still seeing this problem with Maven 2.0.9. There are also open issues on this, e.g. MRELEASE-128 and MRELEASE-325, what exactly is fixed here, as opposed to the other ones?

Show
Havard Bjastad added a comment - Emmanuel, you're saying "Already fixed", but we're still seeing this problem with Maven 2.0.9. There are also open issues on this, e.g. MRELEASE-128 and MRELEASE-325, what exactly is fixed here, as opposed to the other ones?

People

Vote (7)
Watch (6)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.