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
