Yeah well ... as I said, as the projects I had to work on fort he last few years, during the transition to maven there is no way to have all under controll of maven. So I will probably just create my own set of "multi-version" plugin for Maven and Ant and start using this completely dropping usage oft he release plugin.
Chris -----Ursprüngliche Nachricht----- Von: Robert Scholte [mailto:rfscho...@apache.org] Gesendet: Montag, 1. Dezember 2014 20:00 An: Maven Users List Betreff: Re: AW: Problems with the release plugin Just to be sure that we are on the same page: Your request is if the maven-release-plugin could be changed, so you can specify versions for external (i.e. non reactor/multimodule) dependencies. I won't allow this unless it can be automated, hence the introduction of the VersionPolicy. This is a first step towards a solution as asked by the community, which asked for a better way to predict the next version(s). Robert Op Mon, 01 Dec 2014 00:11:46 +0100 schreef Christofer Dutz <christofer.d...@c-ware.de>: > 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 > > > --------------------------------------------------------------------- > 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 ING-DiBa AG, Frankfurt am Main. Registernummer HRB 7727, Handelsregister Amtsgericht Frankfurt am Main. Vorstand: Roland Boekhout (Vorsitzender), Bernd Geilen, Katharina Herrmann, Martin Krebs, Remco Nieland. Aufsichtsrat: Ben Tellings (Vorsitzender) Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
