lundi, mai 31, 2010

Maven release failures

So today I had to generate the MINA 2.0.0 packages in order to launch a vote. We have a full page on MINA web site explaining how to cut a release :

I must say that Maven Release plugin is either totally dumb, or that what it does is totally counter-intuitive, and broken, IMHO.

What is the problem ? The maven release:prepare follows the steps :

1) Check that there are no uncommitted changes in the sources : OK

2) Check that there are no SNAPSHOT dependencies : OK

3) Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use) : OK
(here, we went from 2.0.0-RC2-SNAPSHOT to 2.0.0)

4) Transform the SCM information in the POM to include the final destination of the tag : OK
(the SCM info is now scm:svn:, as expected)

5) Run the project tests against the modified POMs to confirm everything is in working order : OK

6) Commit the modified POMs : KO!!!

What's wrong here ? Everything has been committed in the trunk instead of the expected mina/tags/2.0.0 !

Why is the maven release plugin modifying the SCM tag if it's to commit everything in a place which should store the next version, ie 2.0.1-SNAPSHOT ?

I could understand that this is done on purpose (don't see a single reason for that, but who knows...), but at least, can't it *ask* the user before messing with the trunk ?

Sometime, the Maven Way Of Doing Things (tm) is completely broken, and this explains the complaints found on the blogsphere...

13 commentaires:

Batmat a dit…

Well, you saw that it's doing that to be able to copy that revision to tags, just before going to next required snapshot version?

Maybe it's a limitation that's more SVN oriented, granted. But I think that's because you cannot easily (quickly?) create a tag containing data from somewhere + local only ones + in one go.

And btw, what's the problem? Is that because you don't want your trunk to ever contain such a revision? Since release:prepare will immediately copy this revision and go to next SNAPSHOT, I don't really see the problem.


Arnaud a dit…

What do you have in the file generated in the root directory of the project ?
Which version of the release plugin are you using ?
What happens if you recall release:prepare ? Does it restart where it was stopped ?
I thing the origin of the issue is in scm infos which were wrong :
You had a tags in them instead of a branch or trunk.

Emmanuel Lécharny a dit…

@Batman : I don't expect the plugin to commit in trunk, when everything should be put in Tags. I don't think it has anything to do with SVN, creating a new tags is easy.

And, no, I don't want trunk to be polluted...

olamy a dit…

let the release plugin do everything for you :-)

Emmanuel Lécharny a dit…


release plugin version : 2.0-beta-9

The latest one available...

About what's wrong in my scm infos : that's laughable :) This is *exactly* what Maven release plugin committed when I launched the release:prepare ! Before, it was :


Here is my :

#release configuration
#Mon May 31 14:33:59 CEST 2010\:mina-transport-serial=2.0.1-SNAPSHOT
exec.additionalArguments=-P serial\:mina-transport-serial.empty=true
preparationGoals=clean verify\:mina-integration-xbean=2.0.0\:mina-statemachine=2.0.0\:mina-integration-jmx=2.0.0\:mina-parent=2.0.1-SNAPSHOT\:mina-integration-ognl=2.0.0\:mina-core=2.0.0

Arnaud a dit…

Yes before the release SCM infos were wrong with :
It should be :
52 scm:svn:
I think the problem comes from here. The plugin should have thrown an error.
SCM infos in Mina pom are corrupted since here :

Arnaud a dit…

FYI, latest release plugin version is 2.0.
mvn versions:display-plugin-updates

Emmanuel Lécharny a dit…

Thanks Arnaud ! I will update the plugin version.

And yes, strange enough, the previous SCM was pointing on tags :/

WTF ???

Still thinking that the commit shouldbe done in tags, not in trunk ...

Frédéric a dit…

When showing the svn history of trunk, I appreciate to know "when" I made tags (for example if I don't use bug tracker for every commits)

For example when I fix things, I appreciate to know easily if, for one targetted version, this version packaged my fix (or not).

By commiting on trunk, I'll have :
- rev 100 some comment
- rev 99 [maven-release-plugin] prepare for next dev version
- rev 98 [maven-release-plugin] prepare release 1.1
- rev 97 fix NPE on Foo
- rev 96 [maven-release-plugin] prepare for next dev version
- rev 95 [maven-release-plugin] prepare release 1.0

By not commiting on trunk, I would have :
- rev 98 some comment
- rev 97 [maven-release-plugin] prepare for next dev version
- rev 96 fix NPE on Foo
- rev 95 [maven-release-plugin] prepare for next dev version

Emmanuel Lécharny a dit…

@Frédéric I share your concern, but as soon as the next SNAPSHOT version (ie, N+1) will be committed into trunk, I will be able to *know* when the tags has been done.

Having the SCM pointing to trunk is still a mystery too me up to this point ...

Frédéric a dit…

You can't definetely rely on snapshot version to determine your "precedent release version" ; Plus the snapshot version doesn't appear in svn comments (I added them manually... maybe this could be an improvement in release plugin...)

Nevertheless, I share your point on the fact that "at one moment" (in my example, revision 98 when commiting on trunk), the pom informations are not "relyable".
That is to say if I checkout revision 98 on trunk, I have that points on tags !

Maybe the best workflow would be to :
- change versions (release) in pom.xml
- commit pom.xml on trunk
- copy trunk to tags AND change tag "on the fly"
- commit the tag
- change version (next dev) in pom.xml
- commit pom.xml on trunk

Jukka a dit…

> commit should be done in tags, not in trunk

SVN is a fairly rare exception among SCM systems in that it allows you to commit within a tag. I wouldn't consider doing so a good practice.

Emmanuel Lécharny a dit…

@Jukka Here, I would agree with you. I don't like the tags to be updated *before* everything is ok, but I don't want anything to be injected into trunk until I'm done with the release.

IMO, *if* something must be injected into the SCM, then it should be into a branch. But I don't see a valid reason to commit anything until the release is completed...