Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 2.3
-
Component/s: Git, Mercurial, Subversion
-
Labels:None
-
Environment:HideApache Maven 3.0.4-RC3 (r1210461; 2011-12-05 14:58:54+0100)
Maven home: /usr/local/Cellar/maven/current/libexec
Java version: 1.6.0_29, vendor: Apple Inc.
Java home: /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
Default locale: de_DE, platform encoding: MacRoman
OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"ShowApache Maven 3.0.4-RC3 (r1210461; 2011-12-05 14:58:54+0100) Maven home: /usr/local/Cellar/maven/current/libexec Java version: 1.6.0_29, vendor: Apple Inc. Java home: /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home Default locale: de_DE, platform encoding: MacRoman OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
-
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.
-
- add-tag-to-release-poms.patch
- 20/Dec/11 2:25 PM
- 24 kB
- Mirko Friedenhagen
-
- add-tag-to-release-poms-1329108.patch
- 23/Apr/12 2:38 PM
- 24 kB
- Mirko Friedenhagen
-
- MRELEASE-723-idea.patch
- 02/May/12 6:37 AM
- 4 kB
- Mark Struberg
-
Hide
- testprj-svn-repo.zip
- 03/May/12 1:47 PM
- 36 kB
- Mark Struberg
-
- testprj/conf/authz 1 kB
- testprj/conf/passwd 0.3 kB
- testprj/conf/svnserve.conf 2 kB
- testprj/db/current 0.0 kB
- testprj/db/format 0.0 kB
- testprj/db/fs-type 0.0 kB
- testprj/db/fsfs.conf 2 kB
- testprj/db/min-unpacked-rev 0.0 kB
- testprj/db/rep-cache.db 16 kB
- testprj/db/revprops/0/0 0.0 kB
- testprj/db/revprops/0/1 0.1 kB
- testprj/db/revprops/0/10 0.1 kB
- testprj/db/revprops/0/11 0.2 kB
- testprj/db/revprops/0/12 0.2 kB
- testprj/db/revprops/0/13 0.2 kB
- testprj/db/revprops/0/14 0.2 kB
- testprj/db/revprops/0/15 0.2 kB
- testprj/db/revprops/0/2 0.1 kB
- testprj/db/revprops/0/3 0.1 kB
- testprj/db/revprops/0/4 0.1 kB
- testprj/db/revprops/0/5 0.1 kB
- testprj/db/revprops/0/6 0.2 kB
- testprj/db/revprops/0/7 0.2 kB
- testprj/db/revprops/0/8 0.1 kB
- testprj/db/revprops/0/9 0.1 kB
- testprj/db/revs/0/0 0.1 kB
- testprj/db/revs/0/1 3 kB
- testprj/db/revs/0/10 2 kB
- testprj/db/revs/0/11 1 kB
- testprj/db/revs/0/12 1 kB
-
Hide
- testpr-git.zip
- 03/May/12 2:51 PM
- 39 kB
- Mark Struberg
-
- testpr-git/.git/COMMIT_EDITMSG 0.1 kB
- testpr-git/.git/config 0.1 kB
- testpr-git/.git/description 0.1 kB
- testpr-git/.git/HEAD 0.0 kB
- testpr-git/.git/.../applypatch-msg.sample 0.4 kB
- testpr-git/.git/hooks/commit-msg.sample 0.9 kB
- testpr-git/.git/hooks/post-commit.sample 0.2 kB
- testpr-git/.git/.../post-receive.sample 0.5 kB
- testpr-git/.git/hooks/post-update.sample 0.2 kB
- testpr-git/.git/.../pre-applypatch.sample 0.4 kB
- testpr-git/.git/hooks/pre-commit.sample 2 kB
- testpr-git/.git/hooks/pre-rebase.sample 5 kB
- testpr-git/.../prepare-commit-msg.sample 1 kB
- testpr-git/.git/hooks/update.sample 4 kB
- testpr-git/.git/index 0.3 kB
- testpr-git/.git/info/exclude 0.2 kB
- testpr-git/.git/logs/HEAD 1 kB
- testpr-git/.git/logs/refs/heads/master 1 kB
- testpr-git/.../a73a0d7475b1cd70d86203a9a4e2f703452075 0.1 kB
- testpr-git/.../994bf2ba686d3ef89727dd1f55bc92bd393fcc 0.4 kB
- testpr-git/.../4368f78723579643629e37d47a8495aeb0c758 0.1 kB
- testpr-git/.../55f6e781da27bc42c385471e5afca1146fee58 0.1 kB
- testpr-git/.../bbec59abf9434c344bca00bd2f3df99494fce9 0.7 kB
- testpr-git/.../69805076421c18accf543de2dc7bad205d6315 0.1 kB
- testpr-git/.../d1279f28d2e03db550f28d81df9b8ff7656be7 0.1 kB
- testpr-git/.../e37dbb19a2c029fc7acf6cba8042d3b546824a 0.1 kB
- testpr-git/.../f05f14b8ca2c3c9a64d05384357b98a595e7da 0.2 kB
- testpr-git/.../62cae6cf7c56316e19105c8a83569d994e654e 0.1 kB
- testpr-git/.../f86157f40e851e364ea1c894e9fd02f9c28fb3 0.2 kB
- testpr-git/.../cf4430414c42baf81628ceeea7000bd73f6cc7 0.1 kB
Activity
I now released a private release to my repository manager and tested this with two git projects, which ran fine.
@Robert: the patch is for Mercurial and Subversion as well, could you adapt the components?
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.
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).
@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.
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.
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
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.
Now I am confused
: my patch adds an GitScmTranslator (and HgScmTranslator).
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 ) )
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
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 )
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
> 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.
This is a small sample svn repo which I use. Of course you need to adopt the scm:svn: URL in the poms.
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.
I attached a patch against revision 1213786 of http://svn.apache.org/repos/asf/maven/release/trunk
All existing tests are running successfully.