Maven 2.x Release Plugin

release-pom is changed too much

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
  • Number of attachments :
    0

Description

this needs a full review.

Expressions are populated that shouldn't be (only external settings should be filled in, but not those like basedir or are otherwise path dependant like
project.file...)

basically need to use the pre-interpolation, post inheritence pom... or can we live with the original one without inheritence and just fill in resolved versions?

Issue Links

This issue is related to:
MRELEASE-128 SCM properties being replaced during release:perform Critical Reopened
MRELEASE-114 ${project.artifactId} was replaced with it's value during release:perform Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Porter added a comment -

it is necessary to fill in the super pom details, though.

Show
Brett Porter added a comment - it is necessary to fill in the super pom details, though.
Hide
Permalink
Brett Porter added a comment -

actually, no need to fill in the super pom - the modelVersion will control that.

currently, it warns about the deployed version having fixed versions when using the release pom. This is an issue - we do not want that to be the case. Some more thought is needed here. Perhaps release:perform, using deploy, defaults to not using the release-pom, while generally building from a checkout defaults to using it (ie, commit the release pom containing resolved versions, but release:perform would use -f pom.xml).

Another thought is to revisit why we had release pom. If it is in fact just the versions, then we could go back to populating an extra version tag (eg suggestedVersion) that would be used as the suggested version in conjunction with the given range.

The release pom was meant to capture any other environmental influences at the time, however we don't really have a way to tell which of those actually modify the build and which should be retained (eg profiles that attach artifacts, ${basedir}, etc).

Show
Brett Porter added a comment - actually, no need to fill in the super pom - the modelVersion will control that. currently, it warns about the deployed version having fixed versions when using the release pom. This is an issue - we do not want that to be the case. Some more thought is needed here. Perhaps release:perform, using deploy, defaults to not using the release-pom, while generally building from a checkout defaults to using it (ie, commit the release pom containing resolved versions, but release:perform would use -f pom.xml). Another thought is to revisit why we had release pom. If it is in fact just the versions, then we could go back to populating an extra version tag (eg suggestedVersion) that would be used as the suggested version in conjunction with the given range. The release pom was meant to capture any other environmental influences at the time, however we don't really have a way to tell which of those actually modify the build and which should be retained (eg profiles that attach artifacts, ${basedir}, etc).
Hide
Permalink
John Casey added a comment -

the release pom was meant to create a completely static build, to enable reproduction of a particular release's build from SCM if needed...without pollution from any changes in the environment post-release (or pre-release-where-env-is-stale, I suppose).

The prompt/warning when using the release-pom.xml for release:perform is meant to keep people from releasing a completely static POM. It's possible to build using the release pom, and specify a different pom file to deploy (eg. the regular pom.xml) using a configuration parameter...but I can see where this ability is a bit dangerous.

If we have the release-pom generation turned off by default (as it currently is in SVN, IIRC), then none of this is an issue, right?

Show
John Casey added a comment - the release pom was meant to create a completely static build, to enable reproduction of a particular release's build from SCM if needed...without pollution from any changes in the environment post-release (or pre-release-where-env-is-stale, I suppose). The prompt/warning when using the release-pom.xml for release:perform is meant to keep people from releasing a completely static POM. It's possible to build using the release pom, and specify a different pom file to deploy (eg. the regular pom.xml) using a configuration parameter...but I can see where this ability is a bit dangerous. If we have the release-pom generation turned off by default (as it currently is in SVN, IIRC), then none of this is an issue, right?
Hide
Permalink
Brett Porter added a comment -

we still need to resolve some of the information (see comment above)

Show
Brett Porter added a comment - we still need to resolve some of the information (see comment above)
Hide
Permalink
Al Maw added a comment -

This is biting me very hard indeed. ${user.name} in my scm url is getting rewritten as the interpolated value and committed to CVS. Needless to say, this means that multiple developers can't release the project without an awful lot of manual hacking around whenever the release plug-in is run.

Show
Al Maw added a comment - This is biting me very hard indeed. ${user.name} in my scm url is getting rewritten as the interpolated value and committed to CVS. Needless to say, this means that multiple developers can't release the project without an awful lot of manual hacking around whenever the release plug-in is run.
Hide
Permalink
Brett Porter added a comment -

Al, you're referring to MRELEASE-114

Show
Brett Porter added a comment - Al, you're referring to MRELEASE-114
Hide
Permalink
Emmanuel Venisse added a comment -

Already fixed

Show
Emmanuel Venisse added a comment - Already fixed

People

Vote (5)
Watch (3)

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.