2011/12/15 Phillip Hellewell <ssh...@gmail.com>: > So release:prepare does a compile first and then (modifies the pom and) > creates the tag. That makes sense, but... > > the problem is we have some artifacts that take a *long* time (up to an > hour) to build. During that time developers may check in more changes that > they don't expect to be part of the build (since the build already started). > > The problem occurs because the tag gets created from the latest revision at > the end of the compile. Creating the tag at the end is fine, but it should > create the tag from the revision that was built by release:prepare (e.g., > with svn you can specify an @REV for the source when doing an svn copy).
As you use svn, a possible solution is to use remoteTagging=false (http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#remoteTagging) which do svn cp . http://blbl/tags/ > > Now you're going to say, "that's impossible, because we need to modify the > pom first (version and scm connection)". I knew you were going to say > that. But why not modify the pom upfront, before compiling? Modify it to > what it needs to be for the tag, check it in, and then revert it back and > check that in. Now there exists a revision in the SCM that is appropriate > to tag from at the end of the release:prepare. > > I hope that makes sense. The only downside here is a few unnecessary pom > file checkins, but we'd rather have that than have builds with unexpected > changes in them. Not only that but this would avoid the problem that a > breaking change slips in during the middle of release:prepare and you end > up tagging the broken code and you end up with a worthless tag that can > never be deployed. > > Phillip -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
