Release plugin needs a way to return the SCM urls to previously defined version after release (based on properties)

Details

Type: Improvement
Status: Closed
Priority: Major
Resolution: Won't Fix
Affects Version/s: None
Fix Version/s: None
Component/s: scm
Labels:
None
Environment:
Any pom where SCM information is based on properties

Number of attachments :
0

Description

However, when releasing a parent pom, this isn't an optimal situation. (My) parent poms need to be released by altering the property sets, not changing the SCM urls.

For example,

	<scm>
		<connection>scm:svn:${sird.scm.url.ro}</connection>
		<developerConnection>scm:svn:${sird.scm.url.dev}</developerConnection>
		<url>${sird.scm.url.view}</url>
	</scm>

is based on

		<!-- This is the developer url for this project, made from the scm host, the namespace, and the artifact id -->
		<sird.scm.url.dev>http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk</sird.scm.url.dev>
		<!-- This is the readonly url for this project, made from the scm host, the namespace, and the artifact id -->
		<sird.scm.url.ro>http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk</sird.scm.url.ro>
		<!-- This is the view (eg fisheye) url for this project, made from the scm host, the namespace, and the artifact id -->
		<sird.scm.url.view>http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk</sird.scm.url.view>

What I'd like is to be able to change the sird.scm.url.dev (for instance) to some OTHER value, such as substituting a different url like

		<!-- This is the developer url for this project, made from the scm host, the namespace, and the artifact id -->
		<sird.scm.url.dev>http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk</sird.scm.url.dev>
		<!-- This is the developer url for this project, made from the scm host, the namespace, and the artifact id -->
		<sird.scm.url.released>http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/tags/${releaseTag}</sird.scm.url.dev>
               <releaseTag>blah</releaseTag>

with some property called releaseTag set by the release plugin into my property sets
and then having the release plugin just change the scm url to

	<scm>
           ...
		<developerConnection>scm:svn:${sird.scm.url.released}</developerConnection>
          ...
	</scm>

I know at least a couple of other places that manage a large number of artifacts like to do things like this.

Activity

Ascending order - Click to sort in descending order

Arnaud Heritier made changes - 19/Dec/08 12:37 AM

Field	Original Value	New Value
Component/s		scm [ 12698 ]

Robert Scholte made changes - 03/May/12 1:25 PM

Description

My SCM urls are based on a well-defined pattern utilizing 1 or 2 properties and the artifactId
When the release plugin runs, it overrides these properties with the expanded SCM information, as expected.

However, when releasing a parent pom, this isn't an optimal situation. (My) parent poms need to be released by altering the property sets, not changing the SCM urls.

For example,
<scm>
<connection>scm:svn:${sird.scm.url.ro}</connection>
<developerConnection>scm:svn:${sird.scm.url.dev}</developerConnection>
<url>${sird.scm.url.view}</url>
</scm>

is based on

<sird.scm.url.dev>http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk</sird.scm.url.dev>

<sird.scm.url.ro>http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk</sird.scm.url.ro>

<sird.scm.url.view>http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk</sird.scm.url.view>

What I'd like is to be able to change the sird.scm.url.dev (for instance) to some OTHER value, such as substituting a different url like

<sird.scm.url.dev>http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk</sird.scm.url.dev>

<sird.scm.url.released>http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/tags/${releaseTag}</sird.scm.url.dev>
               <releaseTag>blah</releaseTag>

with some property called releaseTag set by the release plugin into my property sets
and then having the release plugin just change the scm url to

<scm>
           ...
<developerConnection>scm:svn:${sird.scm.url.released}</developerConnection>
          ...
</scm>

I know at least a couple of other places that manage a large number of artifacts like to do things like this.

My SCM urls are based on a well-defined pattern utilizing 1 or 2 properties and the artifactId
When the release plugin runs, it overrides these properties with the expanded SCM information, as expected.

However, when releasing a parent pom, this isn't an optimal situation. (My) parent poms need to be released by altering the property sets, not changing the SCM urls.

For example,
{code:xml}
<scm>
<connection>scm:svn:${sird.scm.url.ro}</connection>
<developerConnection>scm:svn:${sird.scm.url.dev}</developerConnection>
<url>${sird.scm.url.view}</url>
</scm>
{code}
is based on
{code:xml}

<sird.scm.url.dev>http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk</sird.scm.url.dev>

<sird.scm.url.ro>http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk</sird.scm.url.ro>

<sird.scm.url.view>http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk</sird.scm.url.view>
{code}
What I'd like is to be able to change the sird.scm.url.dev (for instance) to some OTHER value, such as substituting a different url like
{code:xml}

<sird.scm.url.dev>http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk</sird.scm.url.dev>

<sird.scm.url.released>http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/tags/${releaseTag}</sird.scm.url.dev>
               <releaseTag>blah</releaseTag>
{code}
with some property called releaseTag set by the release plugin into my property sets
and then having the release plugin just change the scm url to

{code:xml}
<scm>
           ...
<developerConnection>scm:svn:${sird.scm.url.released}</developerConnection>
          ...
</scm>
{code}

I know at least a couple of other places that manage a large number of artifacts like to do things like this.

Hide

Permalink

Robert Scholte added a comment - 03/May/12 1:34 PM

The release:prepare generates a file called release.properties, which contains this kind of information.

Show

Robert Scholte added a comment - 03/May/12 1:34 PM The release:prepare generates a file called release.properties , which contains this kind of information.

Robert Scholte made changes - 03/May/12 1:34 PM

Status	Open [ 1 ]	Closed [ 6 ]
Assignee		Robert Scholte [ rfscholte ]
Resolution		Won't Fix [ 2 ]

Hide

Permalink

Mykel Alvis added a comment - 04/May/12 10:33 AM

The release.properties file doesn't do anything remotely close to what I'm suggesting, but I can't figure out a way to reverse inserting values into the POM.

Show

Mykel Alvis added a comment - 04/May/12 10:33 AM The release.properties file doesn't do anything remotely close to what I'm suggesting, but I can't figure out a way to reverse inserting values into the POM.

Hide

Permalink

Robert Scholte added a comment - 04/May/12 3:34 PM

I'll reopen this issue to give you another chance to explain what you want. I'd prefer if you could attach 3 pom.xml files: pom.xml (the current one), pom.xml.tag (the released one) and pom.xml.next (for the next dev-cycle) to show me what you want.
Keep in mind that we won't add new properties to the pom.

Show

Robert Scholte added a comment - 04/May/12 3:34 PM I'll reopen this issue to give you another chance to explain what you want. I'd prefer if you could attach 3 pom.xml files: pom.xml (the current one), pom.xml.tag (the released one) and pom.xml.next (for the next dev-cycle) to show me what you want. Keep in mind that we won't add new properties to the pom.

Robert Scholte made changes - 04/May/12 3:34 PM

Resolution	Won't Fix [ 2 ]
Status	Closed [ 6 ]	Reopened [ 4 ]

Hide

Permalink

Mykel Alvis added a comment - 04/May/12 4:08 PM

Nope. Sorry. My bad.
I didn't mean that it needed re-opening.

This issue is a losing proposition and after 5 years, doesn't appear to solve the problem I originally wanted it to. Re-close.

Show

Mykel Alvis added a comment - 04/May/12 4:08 PM Nope. Sorry. My bad. I didn't mean that it needed re-opening. This issue is a losing proposition and after 5 years, doesn't appear to solve the problem I originally wanted it to. Re-close.

Mykel Alvis made changes - 04/May/12 4:08 PM

Status	Reopened [ 4 ]	Closed [ 6 ]
Resolution		Won't Fix [ 2 ]

People

Assignee:

Robert Scholte

Reporter:

Mykel Alvis

Vote (0)

Watch (0)

Dates

Created:

07/Feb/07 10:27 AM

Updated:

04/May/12 4:08 PM

Resolved:

04/May/12 4:08 PM