Unfortunately the world isn't as ideal as I would like it to be. There are sometimes constraints that lie outside of the reach of the developer(s) working on the projects build.
In one case the company I worked for desperately needed to release parts of a multi module build separately. I know that this comes with problems, but as long as no other option comes up to reduce the amount of binary data of a new release having to be transfered over an Edge mobile connection, they will have to do partial releases. In my current case the entire company is being switched from Ant to Maven. Switching everything in one big step is completely out of the question. The amount of simultaneous training needed for this is simply not possible. So we have to go a migration path which brings us closer and closer to the final goal of having everything in Maven and be able to use the default maven-release-plugin. But till we are there it feels like there is no way without patching this plugin in order to have an easy transition path. What about some "legacy" or "quirks" mode for the plugin that allows such a thing ... it might even output warnings and pages of text explaining why this mode sucks and should be avoided. All I am asking for is a way to use the plugin without having to hack it which acknowledging that I know this is not ideal, but I am willing to accept the consequences. Chris -----Ursprüngliche Nachricht----- Von: Benson Margulies [mailto:[email protected]] Gesendet: Sonntag, 30. November 2014 13:52 An: Maven Users List Betreff: Re: Problems with the release plugin 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: [email protected] For additional commands, e-mail: [email protected]
