Maven SCM

is it a release plugin issue or a scm git one ?

my guess: the git-push is being executed while the release plugin tags the release.

normally only a

git-push origin tag

is being execute.

Would be awesome if you could provide a full log for me!

I'd be more inclined for the quick-and-easy solution of having the plugin read a parameter/flag that just disables the push entirely. Then, the release plugin user can turn it off for branches he/she does not want to push, and can push at their leisure later.

In fact, I find not pushing to be much more in line with the idea of git to "Play local until confident, push only when ready". After all, we worked so hard to get an SCM system that finally doesn't require us to have connectivity to any remote servers, and having the release plugin PUSH kind of interrupts that achievement.

A simple do-no-push flag seems like a quick solution.

good point! Although this is obvious I have never thought that way.

But this mindset would require to redefine the way the release process currently works - or at least get a different common understanding of it.

Currently releasing an artifact means that it gets tested, tagged and then (with mvn release:perform)a clean checkout happens into target/checkout! How should we do the clean checkout if we do not push the tag into the upstream repo? In the pom.xml there is only a <scm> section which points to upstream, so there is no 'easy' way to do a local checkout from ${basedir}.

Any ideas any1? We first need a fully fledged and consistent user story of the whole picture before we touch the code!

>Currently releasing an artifact means that it gets tested, tagged and then (with mvn release:perform)a clean checkout happens into
> target/checkout! How should we do the clean checkout if we do not push the tag into the upstream repo?

From the local repository.

I don't think any of release:prepare or release:peform should ever think about touching the upstream repository - that should be an entirely user-decided thing. Several reasons:

1) There may not be an upstream repository. Or there may be several – choosing one is purely arbitary
2) the whole release:prepare-> screwup... release:rollback thing is a nightmare with SVN entirely because it has to make a change in the remote repository, which if it goes wrong leaves cruft for all to see.
3) Because I want to squash several release activities together locally into one commit before sending it upstream. Consider:

If I have a multimodule project, with master currently containing
Project A : 1.0-SNAPSHOT
Project B : 3.0-SNAPSHOT

ProjectB depends on ProjectA.

I'm going to do 2 releases
Project A 1.0 -> 1.1-SNAPSHOT
Project B 3.0 -> 3.1-SNAPSHOT

BUT as far as the project is concerned, I only want 1 branch. I.E:

master containing 1.1-SNAPSHOT and 3.1-SNAPSHOT
release-tag-whatever containing 1.0 and 3.0

Currently this would be a bit of a mess.. but that's ok if you don't push upstream. I can use git merge and squash magic to create this result.

Hi Nigel!

I've discussed this in length with Brian and Jason a few weeks ago.
Imho we cannot spare the git-push, because the mvn release:perform will also deploy the artifacts to a public repo!
What happens if the local tag will never get pushed?

I'm not saying that the wish for a local release is not valid, but this would require a mandatory change of the way the release process works. So this is not a simple maven-scm change but mainly one in the release-manager. (There is btw also a wish from Brian to do a 'local checkout' into target/checkout instead of freshly cloning the upstream repo, we should at least keep this in mind.)

How could it work:
$> mvn release:prepare
will do a local tag and does all the build, test, etc

$> mvn release:localperform
will get the local tag, 'export' this tag to target/checkout and does a build test etc on a 'clean' location. This step will not deploy the generated artifacts!

$> mvn release:publish
will push the tag to the upstream repo and maybe deploy the previously generated artifacts to the public repo.
I personally would like to mandatorily have a clone from the upstream repo and then do a clean local build first instead of the direct deploy.
This sounds paranoid at the first glimpse, but from the point of safety it's more mature.

Btw, the 2 branches in your example cannot be handled even in SVN. You only can do this by manually tagging. But since git and hg always taggs the whole repo (there is no way to tag single directories!), it's not applicable to most distributed SCMs anyway.

LieGrue,
strub

Won't fix ?

I've not been following this issue for a while - but the problem has happened to several of my colleagues. My opinion is that the push is important, it should be done. But it should only be done for the current branch. I think the preferred behaviour should be to issue the following:

git push origin <currentbranch>

That should be a simple fix and should handle most of the problems people experience. And I would be quite unhappy with a 'wontfix' classification, because it is a real problem that does occur fairly regularly if you use git and the release plugin.

Petter, pushing to the current branch should already be the default behaviour.

We also had a discussion about whether we should add more support for distributed SCMs in maven-scm-api in the future, because bazaar, hg, etc works the same way basically.

There are 2 issues:

• The current way of always pushing is good for projects like we have here at Apache and a few other pretty centralised projects where basically only 1 main repository exists. But it the project is more a forked pull-it-from-wherever-you-need approach, this probably wont work for the long term. Another idea is that it would make testing releases a lot easier. You do a 'local' release and push it to a staging repo. If all works out fine then you can push the tag to the central repo...

• For release:perform we currently do a git-clone from the upstream repo. This may cause some unnecessary traffic (and time). This is not such a big problem for git but for hg and bazaar which performs a lot slower. Since with all DCMS we have the full repo available locally, we may easily checkout into target/checkout from our local repo instead of going to the remote.

Personally, I'd prefer the current implementation not do any operations with an upstream repository by default (though offer options to do so on commit/update). This would make it forwards compatible with an API that understands the concept of upstream repositories, and works for all users' cases. I don't think it's unexpected that there'd be no upstream repository, or that there may be multiple in this case, and it's a bit odd to make a guess.

The way we use it at work, we do have a central repository so for us I would say pushing (of + to the current branch only) is desirable or at least ok. Off the top of my head, I can't think of any real issues with not pushing - we could just do that manually. Even for more truly distributed source management, though, I would say that the nature of making a release involves publishing the artifacts, so it would make some sort of sense to also publish the source code (in a better way than a jarball Maven artifact). But I guess that part of it could be seen as a separate thing - if somebody wants the tag that corresponds to the released code, you just have to pull it from whoever happened to make that release. So from my perspective, Brett's suggestion about not pushing sounds fine.

On another note, I would hate to work on a combination of Maven + completely distributed source. Handling SNAPSHOT releases would be hell, or at least, you couldn't do it using a shared repo. Even without a central repo for snapshots, conflicts where my project A version depends on a project B 1.2-SNAPSHOT that is completely different from somebody else's project B 1.2-SNAPSHOT are likely and hard to troubleshoot. I guess some addition to Maven's snapshot concept would be required for that to work.

Petter, I think I have pretty much the same understanding of this.

I think it's a fact that <distributionManagement> and <scm> have to be in sync, so whenever I release an artifact, it should be correctly deployed AND tagged at the same time. Thus, imho the push is mandatory. If I like to fork a project, then I'll have to change both scm and deployment sections in my pom.

If I like to do local releases, I can still perform a local clone, so the push to the upstream repo is local!

Okay, just my opinion: I run into that problem, too. I really hate that push. I prefer to do that manually after everything worked as expected. And sometimes I prefer to adjust that commits too (multi module projects).
At the moment I end up deleting tags from origin and often doing a "git push -f" if something failed (e.g. site generation)...
That does not seem to be the best solution...

Others here have also said, that they prefer not being forced to push to origin. So there are the user stories you asked for.

So the solution seems to be very simple:

• Clone from ${basedir} instead of origin during the release. That might solve some other issues too (performance, traffic, merge conflicts when origin has changed in between).
• Make the push optional! That allows everybody to follow his preferred work flow.

While I strongly believe that distributed VCS never should push automatically, I accept that some people out there are still "brainwashed" by the use of a centralized VCS for decades.
So for me it is ok, to push by default. But please offer an option to skip that...

By the way: Thanks for your work...

Johannes, it's not about what people got used to but more about having kind of a 'common commit' (in the SQL commit way). While I see the wish to omit the push, we have to make sure that the tag gets pushed if the artifacts are going to be pushed to a public repo.

My ideal scenario would be that we do not push if you do a release:stage but push if you do a release:perform.
Ideally this would also integrate with nexus:staging-finish in an elegant way.

Mark: You are right. In an ideal world we would have transactions everywhere. Like in SQL. Then I'd prefer a separate step that uploads the artifacts to the repository and tags the "central" VCS repository within one transaction. And of course that step should support rollback...
(Maybe this might be a thing that should be implemented for Maven 4? I really love that idea...).

But at the moment Maven is far from that.

And to be honest, I don't see your point in "we have to make sure that the tag gets pushed if the artifacts are going to be pushed to a public repo".
I understand that you try to keep the source and artifact repositories as consistent as possible. But the current situation is really not that good.
When a release is done (with SVN) first the tag is created, then the sources are checked out and build. And finally deployed to the artifact repository.
A bigger project that has many modules may take several hours to build (especially site!). So you have inconsistent repositories at least for some time. Guaranteed! For every release.
So consistency is a good wish. But nothing more. And faking pseudo consistency through forced pushes is not the solution.

By the way: How does Maven handle commits/pushes to the source repository during release? I think that could/will brake the release, won't it?

The downside of the forced pushes is obvious: It is not possible to test Maven releases. So quite often Maven releases fail (at least in my projects, but maybe I am just unlucky). And every failed release pollutes the source repository. With Git it is possible to clean that up. With Subversion it is not...

My conclusion: We cannot ensure consistency between source and artifact repository. All we can do, is to fake some type of hopefully-will-be-consistent-in-a-few-minutes-again thing.
So just drop that idea until some real transaction support can be added. Until then, let the developer decide.
Just give us an option. I am not begging that you change your workflow. Just try to see the disadvantages of the current behaviour and give us an option to avoid them...

The additional release:stage seems to be a good idea. It helps to solve problematic release.
But it does not solve the issue of consistency. When release:perform just uploads the artifacts and tags the source repository, several problems might occur:

• One of them fails and we have a nice inconsistency (just think about permission issues or network problems)
• at least we have a short time where those repositories are not consistent

I also think the push (and any access to remote repository) is unwarranted. It should be up to the developer to ensure that <scm> and <distributionManagement> are in sync. Maven can never guarantee this anyway---who's to say that <distributionManagement> does not point to a private/local repository?

I have to agree with making the push optional. I work on a small project, we're two developers, we don't have an upstream repository, but we still do releases. Being forced to a push makes no sense as there's nowhere to push to. The tag itself is all that's required in this case.

No need to change the default behaviour, just make the push optional.

GIT is a distributed SCM. There IS NO CENTRAL repository. Accept it.

Doing a push during the release process is counter to the GIT model.

It's totally valid to just use a local GIT repository that has NO remote repositories associated with it. There would be NOTHING to "push" to! It could be that my local repo IS the upstream repository. And folks pull from my local repo.

PLEASE PLEASE don't push during the release process. If folks want to push their release to another remote repo they can easily do that outside of the maven release process using the git push command.

Hiram, I think that even if Git is distributed, Maven isn't, and when making a Maven release, it kind of makes sense to allow the Maven model to override the Git model. In case you want a more in-depth explanation of what I mean, I thought it was interesting enough for a blog post: http://pettermahlen.wordpress.com/2010/02/20/git-and-maven/.

Hi Petter,

I think maven and git are actually on the same model in this regard.

Even in maven a 'release' can be staged and then 'dropped' via something like a nexus repository manger.
Git also hase a similar feature. You can commit local changes and then use 'git rebase -i' to drop previous commits. It re-writes local history so that it looks like the commit never happend.

But this feature only works if you have NOT pushed the changes to a remote repo. You can't re-write the history of a remote git repo.

So, the 'release' plugin does not necessarily push a release to public repos (since it can be dropped in staging), then a the release plugin should not push a release in to the public scm repo either.

If the the release gets manually promoted in staging, then it can also be manually pushed from the local git repo to the publicly shared repo.

Attaching a patch which added a 'pushChanges' configuration setting to the scm plugin.
And update the git provider to check it so you can disable pushing changes.

The setting will probably come in handy for the other distributed SCM implementations.

For those of you using git.. the patch can be accessed at:
http://github.com/chirino/maven-scm/tree/trunk/maven-scm-providers/

Please note that the issue as /originally/ filed can be solved using git >= v1.6.3 using the following configuration:

git config push.default current

("tracking" option may also be used to the same effect, a --global flag can also be used to make this global default)

See the push.default option on the following page http://www.kernel.org/pub/software/scm/git/docs/git-config.html

Git 1.6.3 was not published at the time this issue was created. As we speak I believe most platforms have >=1.6.3 in their available releases, so I am not sure this
issue should be fixed for /this/ reason - although there may be other sensible use cases for this

(Additionally I am also a bit sceptical at the "git fu" in use for the release plugin. I really think the "released" version shouldn't be in the history of the "master" branch, it should be a separate tag, as can be seen from the "1.2" release in the attached image (http://jira.codehaus.org/secure/attachment/47698/release_branch.jpg). The "1.2.1" as shown in the image is made with the release plugin. From the perspective of "push", I think the tag can/should be pushed, possibly even force pushed. Force could be used when re-rolling releases)

fixed in rev 922043

Does anyone have a working example of git + the pushChanges=false configuration?

If there's no upstream git repository, what should one put in the scm section? And does one tell maven to use the 1.4 git scm provider? Is it's not released yet, is there any ETA for it?

I would also like to know. I guess it's because the change is only in a snapshot plugin? Do you know what version you're running?

In my scm config i have scm:git:file//./ - works well for release:prepare, but not for release:perform

Tony - good idea with the git:file://./ - I was assuming it would be something similar to that. Locally it looks like 1.1 is being downloaded, I guess the scm plugins moved from 1.1 directly to 1.4?

When I say it works well, it works, but it does still push up to origin.

Can someone give an example of changes to my pom.xml to pull in the 1.4-SNAPSHOT and add the pushChanges=false option? Only 1.3 is available in maven central..

Any clues when we can expect the 1.4 release?

I tried to test it with 1.4-SNAPSHOT, but it didn't work for me.

With following configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-scm-plugin</artifactId>
<version>1.4-SNAPSHOT</version>
<configuration>
<pushChanges>false</pushChanges>
</configuration>
</plugin>

mvn release:prepare does:
[INFO] [release:prepare {execution: default-cli}]
[INFO] Resuming release from phase 'scm-commit-release'
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /home/mm/fooproj && git add – pom.xml
[INFO] Working directory: /home/mm/fooproj
[INFO] Executing: /bin/sh -c cd /home/mm/fooproj && git status
[INFO] Working directory: /home/mm/fooproj
[INFO] Executing: /bin/sh -c cd /home/mm/fooproj && git commit --verbose -F /tmp/maven-scm-1744449456.commit pom.xml
[INFO] Working directory: /home/mm/fooproj
[INFO] Executing: /bin/sh -c cd /home/mm/fooproj && git symbolic-ref HEAD
[INFO] Working directory: /home/mm/fooproj
[INFO] Executing: /bin/sh -c cd /home/mm/fooproj && git push ssh://fooproj.git.sourceforge.net/gitroot/fooproj/fooproj master:master
[INFO] Working directory: /home/mm/fooproj
mm@fooproj.git.sourceforge.net's password:

Did I do something wrong?

yes
You have to use/configure maven-release-plugin 2.1-SNAPSHOT and not maven-scm-plugin

How does this work tho... if the release plugin stops you from having SNAPSHOTs in your pom.xml - how do you use the SNAPSHOT release plugin? Or does it ignore that reference...

have a look at http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#allowTimestampedSnapshots
and maven probably ask you if you are sure about using SNAPSHOT for your release

Thanks Olivier for a quick reply. That helped .
allowTimestampedSnapshots works fine for me.

Just wanna make clear, that version 2.1 of the release plugin has been released some time ago. So no need to use the Snapshot version....