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

DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3
    • Component/s: Git, Mercurial, Subversion
    • Labels:
      None
    • Environment:
    • Flags:
      Patch

      Description

      With SVN the developerConnection and connection are
      updated to the "real" release URL, that is when I invoke release:prepare with
      a URL like:
      https://SVNSERVER/svn/REPO/myproject/branches/release it will be
      replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0
      which is fine because now you know which revision to checkout for
      building the release.

      With git there is no such possibility to realize this with rewriting
      the URL AFAIK. So I would have expected however, that maybe the //project/scm/tag
      element would be updated to reflect the fact, that the pom is the one
      of release, either to the "symbolic name" myproject-1.0 or to the hash
      of the tag.

      See http://markmail.org/thread/m77cvhqqq56krzzd as well.

      1. add-tag-to-release-poms.patch
        24 kB
        Mirko Friedenhagen
      2. add-tag-to-release-poms-1329108.patch
        24 kB
        Mirko Friedenhagen
      3. MRELEASE-723-idea.patch
        4 kB
        Mark Struberg
      4. testprj-svn-repo.zip
        36 kB
        Mark Struberg
      5. testpr-git.zip
        39 kB
        Mark Struberg

        Activity

        Hide
        Mirko Friedenhagen added a comment -

        I attached a patch against revision 1213786 of http://svn.apache.org/repos/asf/maven/release/trunk
        All existing tests are running successfully.

        Show
        Mirko Friedenhagen added a comment - I attached a patch against revision 1213786 of http://svn.apache.org/repos/asf/maven/release/trunk All existing tests are running successfully.
        Hide
        Mirko Friedenhagen added a comment -

        I now released a private release to my repository manager and tested this with two git projects, which ran fine.

        Show
        Mirko Friedenhagen added a comment - I now released a private release to my repository manager and tested this with two git projects, which ran fine.
        Hide
        Mirko Friedenhagen added a comment -

        Edit version and components.

        Show
        Mirko Friedenhagen added a comment - Edit version and components.
        Hide
        Mirko Friedenhagen added a comment -

        @Robert: the patch is for Mercurial and Subversion as well, could you adapt the components?

        Show
        Mirko Friedenhagen added a comment - @Robert: the patch is for Mercurial and Subversion as well, could you adapt the components?
        Hide
        Robert Scholte added a comment -

        Mirko, I've created Mercurial and Subversion as MRELEASE-components and added them to this issue. This makes me wonder if these classes shouldn't be moved to SCM, but that's another discussion.

        Show
        Robert Scholte added a comment - Mirko, I've created Mercurial and Subversion as MRELEASE-components and added them to this issue. This makes me wonder if these classes shouldn't be moved to SCM, but that's another discussion.
        Hide
        Mark Struberg added a comment -

        Please review if the <tag> info didn't get abused before you fix this issue!
        This information might have been used to 'tweak' the <scm> URL. I already found a few cases where such SCM-Url hack not only have been applied for SVN but also for other SCMs. (e.g. adding the submodule name to the SCM-URL).

        Show
        Mark Struberg added a comment - Please review if the <tag> info didn't get abused before you fix this issue! This information might have been used to 'tweak' the <scm> URL. I already found a few cases where such SCM-Url hack not only have been applied for SVN but also for other SCMs. (e.g. adding the submodule name to the SCM-URL).
        Hide
        Mirko Friedenhagen added a comment -

        @Mark: I do not think it will be a problem for Git or Mercurial as there was no support for this right now. In regards to subversion using tag is probably unneeded as the SCM-URL is unique already? I would be willing to edit the patch to exclude the subversion usecase but think it to be valuable for the DVCSes.

        Show
        Mirko Friedenhagen added a comment - @Mark: I do not think it will be a problem for Git or Mercurial as there was no support for this right now. In regards to subversion using tag is probably unneeded as the SCM-URL is unique already? I would be willing to edit the patch to exclude the subversion usecase but think it to be valuable for the DVCSes.
        Hide
        Mirko Friedenhagen added a comment -

        Modify patch to work with r1329108.

        Show
        Mirko Friedenhagen added a comment - Modify patch to work with r1329108.
        Hide
        Robert Scholte added a comment -

        SYNOPSIS:
        git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]
        <tagname> [<commit> | <object>]
        git tag -d <tagname>…
        git tag [-n[<num>]] -l [--contains <commit>] [--points-at <object>]
        [<pattern>…]
        git tag -v <tagname>…

        Together with
        GitTagCommand it looks like this should already work.

        Show
        Robert Scholte added a comment - SYNOPSIS: git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <tagname> [<commit> | <object>] git tag -d <tagname>… git tag [-n [<num>] ] -l [--contains <commit>] [--points-at <object>] [<pattern>…] git tag -v <tagname>… Together with GitTagCommand it looks like this should already work.
        Hide
        Mirko Friedenhagen added a comment -

        Hello Robert,

        at least with Git I have not seen any /project/scm/tag element added to the released pom when running mvn release:prepare. See https://github.com/1and1/testlink-junit/blob/net.oneandone.testlinkjunit-3.0.2/pom.xml for an example.

        Regards
        Mirko

        Show
        Mirko Friedenhagen added a comment - Hello Robert, at least with Git I have not seen any /project/scm/tag element added to the released pom when running mvn release:prepare . See https://github.com/1and1/testlink-junit/blob/net.oneandone.testlinkjunit-3.0.2/pom.xml for an example. Regards Mirko
        Hide
        Robert Scholte added a comment -

        I've done some extra investigation: The git-scm-provider supports it, but there's no GitScmTranslator and so the rewrite is skipped. So I can agree with Mark that your proposal isn't the right solution.
        I'll push this forward to 2.4, so we start preparing a new release.

        Show
        Robert Scholte added a comment - I've done some extra investigation: The git-scm-provider supports it, but there's no GitScmTranslator and so the rewrite is skipped. So I can agree with Mark that your proposal isn't the right solution. I'll push this forward to 2.4, so we start preparing a new release.
        Hide
        Mirko Friedenhagen added a comment -

        Now I am confused : my patch adds an GitScmTranslator (and HgScmTranslator).

        Show
        Mirko Friedenhagen added a comment - Now I am confused : my patch adds an GitScmTranslator (and HgScmTranslator).
        Hide
        Mark Struberg added a comment -

        This sounds reasonable, I'll give the patch a try today.

        Show
        Mark Struberg added a comment - This sounds reasonable, I'll give the patch a try today.
        Hide
        Mark Struberg added a comment -

        I've now reviewed the patch and think we need to think a bit harder about this

        a.) The ScmTranslator was a perfect starting point, but I think it's not yet full cycle.

        You added the code:
        public String resolveTag( String tag )
        {
        if ( !"HEAD".equals( tag ) )

        { return tag; }

        else

        { return null; }

        }

        but there is no special 'HEAD' tag in GIT nor hg. I assume you've copied that over from the CvsScmTranslator, right? So this doesn't suite for GIT and we should just return tag instead.

        I like to try another route:
        Currently we had to add a new ScmTranslator for all new SCMs, but that doesn't scale.
        I've now created a new DefaultScmTranslator which will get created if NO other (special) ScmTranslator gets picked up. This one just returns the unchanged URLs and the tag.

        The main change is that we now allways rewrite the pom and set the tag!

        PS:I've kept your unit tests (but didn't yet fix the code style).
        PPS: We need to review the HEAD stuff in the other ScmTranslators as well (e.g. ClearCase).
        PPPS: will upload the patch after fixing the tests

        Show
        Mark Struberg added a comment - I've now reviewed the patch and think we need to think a bit harder about this a.) The ScmTranslator was a perfect starting point, but I think it's not yet full cycle. You added the code: public String resolveTag( String tag ) { if ( !"HEAD".equals( tag ) ) { return tag; } else { return null; } } but there is no special 'HEAD' tag in GIT nor hg. I assume you've copied that over from the CvsScmTranslator, right? So this doesn't suite for GIT and we should just return tag instead. I like to try another route: Currently we had to add a new ScmTranslator for all new SCMs, but that doesn't scale. I've now created a new DefaultScmTranslator which will get created if NO other (special) ScmTranslator gets picked up. This one just returns the unchanged URLs and the tag. The main change is that we now allways rewrite the pom and set the tag! PS:I've kept your unit tests (but didn't yet fix the code style). PPS: We need to review the HEAD stuff in the other ScmTranslators as well (e.g. ClearCase). PPPS: will upload the patch after fixing the tests
        Hide
        Mark Struberg added a comment -

        basic approach without unit tests yet.

        Show
        Mark Struberg added a comment - basic approach without unit tests yet.
        Hide
        Robert Scholte added a comment -

        Mirko, just to clearify myself a bit: it looks to me that the String translateTagUrl( String url, String tag, String tagBase ) is the one which should be implemented instead of the String resolveTag( String tag )

        Show
        Robert Scholte added a comment - Mirko, just to clearify myself a bit: it looks to me that the String translateTagUrl( String url, String tag, String tagBase ) is the one which should be implemented instead of the String resolveTag( String tag )
        Hide
        Mirko Friedenhagen added a comment -

        Robert, thanks for the clarification.

        I had a look into Mark's patch and to me it looks like Mark is on the right trail by implementing a DefaultScmTranslator which does not fiddle around at all with given tags or urls and is IMHO appropriate out of the box at least for Bazaar, Mercurial and Git (and probably even for CVS, as I do not think anyone will "release" a version called HEAD anyway). The only SCM I know of which fiddles around with urls and tags and branches is Subversion.

        So what's next? Mark, will you take care of this issue from now on? When I could be of help nonetheless we should find a way to share work, thought without a DCVS this will be harder .

        Regards
        Mirko

        Show
        Mirko Friedenhagen added a comment - Robert, thanks for the clarification. I had a look into Mark's patch and to me it looks like Mark is on the right trail by implementing a DefaultScmTranslator which does not fiddle around at all with given tags or urls and is IMHO appropriate out of the box at least for Bazaar, Mercurial and Git (and probably even for CVS, as I do not think anyone will "release" a version called HEAD anyway). The only SCM I know of which fiddles around with urls and tags and branches is Subversion. So what's next? Mark, will you take care of this issue from now on? When I could be of help nonetheless we should find a way to share work, thought without a DCVS this will be harder . Regards Mirko
        Hide
        Mark Struberg added a comment -

        > it looks to me that the String translateTagUrl
        hmm, don't think so. In GIT (like in CVS) the SCM URL doesn't change at all for a new TAG or BRANCH.
        The only thing we need to do is to set the <tag> in the SCM info. As far as I've understood this is what the resolveTag method is for, isn't?

        PS: I'l take care, but I'm really happy for your feedback folks! This one is pretty fundamental and I don't like to trash the release manager (again) Otoh I don't hesitate to make important changes if there is a good reason. This one feels like one.

        Show
        Mark Struberg added a comment - > it looks to me that the String translateTagUrl hmm, don't think so. In GIT (like in CVS) the SCM URL doesn't change at all for a new TAG or BRANCH. The only thing we need to do is to set the <tag> in the SCM info. As far as I've understood this is what the resolveTag method is for, isn't? PS: I'l take care, but I'm really happy for your feedback folks! This one is pretty fundamental and I don't like to trash the release manager (again) Otoh I don't hesitate to make important changes if there is a good reason. This one feels like one.
        Hide
        Mark Struberg added a comment -

        This is a small sample svn repo which I use. Of course you need to adopt the scm:svn: URL in the poms.

        Show
        Mark Struberg added a comment - This is a small sample svn repo which I use. Of course you need to adopt the scm:svn: URL in the poms.
        Hide
        Mark Struberg added a comment -

        and here comes the git repo

        Show
        Mark Struberg added a comment - and here comes the git repo
        Hide
        Mark Struberg added a comment -

        fixed in r1333660.

        I've now used the explicit GitScmTranslator and HgScmTranslator. The generic fix would have been a way to big change. Tested with SVN and GIT.

        Show
        Mark Struberg added a comment - fixed in r1333660. I've now used the explicit GitScmTranslator and HgScmTranslator. The generic fix would have been a way to big change. Tested with SVN and GIT.

          People

          • Assignee:
            Mark Struberg
            Reporter:
            Mirko Friedenhagen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development