On Tue, Dec 2, 2014 at 3:08 AM, Dutz, Christofer <[email protected]> wrote: > 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.
I really think that you are better off releasing 'manually' in the transition. I think you will discover that it is not so easy to change the release plugin to 'just relax a constraint' and still get a coherent result. > > Chris > > -----Ursprüngliche Nachricht----- > Von: Robert Scholte [mailto:[email protected]] > 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 > <[email protected]>: > >> 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:[email protected]] >> 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 >> <[email protected]> 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:[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] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
