maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <rfscho...@apache.org>
Subject Re: AW: Problems with the release plugin
Date Mon, 01 Dec 2014 19:00:10 GMT
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.dutz@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:bimargulies@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.dutz@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:bimargulies@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message