Maven Release Plugin
  1. Maven Release Plugin
  2. MRELEASE-196

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

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major 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

      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

      		<!-- 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

        Hide
        Robert Scholte added a comment -

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

        Show
        Robert Scholte added a comment - The release:prepare generates a file called release.properties , which contains this kind of information.
        Hide
        Mykel Alvis added a comment -

        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 - 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
        Robert Scholte added a comment -

        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 - 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.
        Hide
        Mykel Alvis added a comment -

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

          People

          • Assignee:
            Robert Scholte
            Reporter:
            Mykel Alvis
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: