maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dutz, Christofer" <>
Subject AW: AW: Problems with the release plugin
Date Tue, 02 Dec 2014 08:08:23 GMT
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.


-----Ursprüngliche Nachricht-----
Von: Robert Scholte [] 
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).


Op Mon, 01 Dec 2014 00:11:46 +0100 schreef Christofer Dutz

> 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 []
> 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 
> <> 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 []
>> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

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:
For additional commands, e-mail:

View raw message