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 Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3
    • Component/s: Git, Mercurial, Subversion
    • Labels:
      None
    • Environment:
    • Testcase included:
      yes
    • Patch Submitted:
      Yes
    • Number of attachments :
      5

      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

        Activity

        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: