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
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:
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.
Cheers
What do you have in the file release.properties 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 :
http://svn.apache.org/viewvc/mina/trunk/pom.xml?r1=901210&r2=949728&diff_format=h
You had a tags in them instead of a branch or trunk.
@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...
let the release plugin do everything for you :-)
@Arnaud
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 :
scm:svn:http://svn.apache.org/repos/asf/mina/tags/build-2.0.0-RC2-SNAPSHOT
http://svn.apache.org/viewvc/directory/mina/tags/build-2.0.0-RC2-SNAPSHOT
scm:svn:https://svn.apache.org/repos/asf/mina/tags/build-2.0.0-RC2-SNAPSHOT
Here is my release.properties :
#release configuration
#Mon May 31 14:33:59 CEST 2010
project.dev.org.apache.mina\:mina-transport-serial=2.0.1-SNAPSHOT
completedPhase=scm-commit-release
project.rel.org.apache.mina\:build=2.0.0
project.scm.org.apache.mina\:mina-statemachine.empty=true
project.scm.org.apache.mina\:mina-integration-xbean.empty=true
exec.additionalArguments=-P serial
project.scm.org.apache.mina\:mina-transport-serial.empty=true
scm.tagBase=https\://svn.apache.org/repos/asf/mina/tags
scm.tag=2.0.0
project.rel.org.apache.mina\:mina-transport-serial=2.0.0
project.scm.org.apache.mina\:build.tag=HEAD
project.rel.org.apache.mina\:mina-integration-beans=2.0.0
project.scm.org.apache.mina\:build.developerConnection=scm\:svn\:https\://svn.apache.org/repos/asf/mina/tags/build-2.0.0-RC2-SNAPSHOT
project.rel.org.apache.mina\:mina-transport-apr=2.0.0
project.dev.org.apache.mina\:mina-integration-jmx=2.0.1-SNAPSHOT
project.dev.org.apache.mina\:mina-integration-xbean=2.0.1-SNAPSHOT
project.scm.org.apache.mina\:mina-parent.empty=true
project.rel.org.apache.mina\:mina-parent=2.0.0
project.scm.org.apache.mina\:mina-transport-apr.empty=true
project.dev.org.apache.mina\:mina-statemachine=2.0.1-SNAPSHOT
project.dev.org.apache.mina\:build=2.0.1-SNAPSHOT
project.scm.org.apache.mina\:build.connection=scm\:svn\:http\://svn.apache.org/repos/asf/mina/tags/build-2.0.0-RC2-SNAPSHOT
project.rel.org.apache.mina\:mina-filter-compression=2.0.0
project.dev.org.apache.mina\:mina-filter-compression=2.0.1-SNAPSHOT
remoteTagging=true
project.scm.org.apache.mina\:mina-integration-jmx.empty=true
project.scm.org.apache.mina\:mina-integration-beans.empty=true
scm.url=scm\:svn\:https\://svn.apache.org/repos/asf/mina/tags/build-2.0.0-RC2-SNAPSHOT
project.scm.org.apache.mina\:build.url=http\://svn.apache.org/viewvc/directory/mina/tags/build-2.0.0-RC2-SNAPSHOT
project.scm.org.apache.mina\:mina-core.empty=true
scm.commentPrefix=[maven-release-plugin]
project.dev.org.apache.mina\:mina-core=2.0.1-SNAPSHOT
project.scm.org.apache.mina\:mina-example.empty=true
project.dev.org.apache.mina\:mina-example=2.0.1-SNAPSHOT
project.rel.org.apache.mina\:mina-example=2.0.0
project.dev.org.apache.mina\:mina-integration-ognl=2.0.1-SNAPSHOT
project.dev.org.apache.mina\:mina-legal=2.0.1-SNAPSHOT
project.scm.org.apache.mina\:mina-integration-ognl.empty=true
project.scm.org.apache.mina\:mina-legal.empty=true
project.dev.org.apache.mina\:mina-integration-beans=2.0.1-SNAPSHOT
project.dev.org.apache.mina\:mina-transport-apr=2.0.1-SNAPSHOT
project.rel.org.apache.mina\:mina-legal=2.0.0
project.scm.org.apache.mina\:mina-filter-compression.empty=true
preparationGoals=clean verify
project.rel.org.apache.mina\:mina-integration-xbean=2.0.0
project.rel.org.apache.mina\:mina-statemachine=2.0.0
project.rel.org.apache.mina\:mina-integration-jmx=2.0.0
project.dev.org.apache.mina\:mina-parent=2.0.1-SNAPSHOT
project.rel.org.apache.mina\:mina-integration-ognl=2.0.0
project.rel.org.apache.mina\:mina-core=2.0.0
Yes before the release SCM infos were wrong with :
scm:svn:http://svn.apache.org/repos/asf/mina/tags/build-2.0.0-RC2-SNAPSHOT
http://svn.apache.org/viewvc/directory/mina/tags/build-2.0.0-RC2-SNAPSHOT
scm:svn:https://svn.apache.org/repos/asf/mina/tags/build-2.0.0-RC2-SNAPSHOT
It should be :
scm:svn:http://svn.apache.org/repos/asf/mina/trunk
51 http://svn.apache.org/viewvc/directory/mina/trunk
52 scm:svn:https://svn.apache.org/repos/asf/mina/trunk
I think the problem comes from here. The plugin should have thrown an error.
SCM infos in Mina pom are corrupted since here : http://svn.apache.org/viewvc/mina/trunk/pom.xml?r1=764005&r2=764010
FYI, latest release plugin version is 2.0.
mvn versions:display-plugin-updates
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 ...
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
(1.2-SNAPSHOT)
- rev 98 [maven-release-plugin] prepare release 1.1
(1.1-SNAPSHOT)
- 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
(1.2-SNAPSHOT)
- rev 96 fix NPE on Foo
- rev 95 [maven-release-plugin] prepare for next dev version
(1.1-SNAPSHOT)
@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 ...
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
> 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.
@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...
Enregistrer un commentaire