Oh well ... I give up ... so yet another plugin it will be. I wasn't talking about changing anything at the workflow, just to have one enforced constraint loosended a little if required, but I guess this will never happen.
Chris -----Ursprüngliche Nachricht----- Von: Benson Margulies [mailto:bimargul...@gmail.com] Gesendet: Sonntag, 30. November 2014 22:22 An: Maven Users List Betreff: Re: Problems with the release plugin The release plugin is a tool that does a specified set of steps. It's built out of reusable components. Turning it into MS Word with 10,000,000 options is not, in my view, a good plan. If you can write down a clear spec for an alternative workflow, you can study the source and make a plugin. That's what the owners of the gitflow-maven-plugin did. It's an alternative release plugin with a different workflow. On Sun, Nov 30, 2014 at 11:44 AM, Christofer Dutz <christofer.d...@c-ware.de> wrote: > 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:bimargul...@gmail.com] > 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: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
