I'm going to attempt a summary here. The release plugin has a requirement. It must be true that you can go to the SCM, checkout a brand new copy of the tree rooted at the <scm/> element, _change the versions_ in the pom(s), and run a build as configured by the profiles and goals. If that's not true, the release process will fail, and possibly leave you with a manual cleanup in the SCM. There are many ways to set up a build that seems just fine but fails this test.
The top of this thread is a plea for a 'dry run' that is a perfect simulation of this, so that users can flush this out before it bites them, and that it should not be hard to ask for this. It seems to me that it should not be hard, in a typical automated build system (Jenkins, etc.) to set up a build that does exactly this. Checkout a clean tree, run the maven-versions-plugin to set a dummy version, and run a build, with profiles and goals to match the eventual release. Eat one of these apples every day, and you won't be visiting the maven doctor so often. It seems to me that it should also not be terribly hard to make this a feature of the maven-release-plugin. As a further wrinkle, there's the question of tag management, which might be seen as interrelated to the lengthy threads here and elsewhere about never, ever, deleting a tag. I wonder about yet another m-r-p parameter: a staging SCM URL, distinct from the <scm/> stock identifiers. m-r-p would pull from <scm/> but push to this other place. Then, a human could decide if the release is real, and, if so, push the commits and tag to the real, immutable, repo. I'm not qualifier to judge whether this can work for anything other than git, but git sure is popular. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
