Hi Robert, Thanks for your reply, but I have encountered numerous situations where this restriction resulted in people not using the pulugin at all ... doing each step with alternate plugins and unfortunately leaving away some of the steps.
So ususally they use the versions plugin or manually adjust the versions. Commit Tag Build & Deploy Update to the next version Comit again completely skipping some of the usual additional testing steps I know that handling the commandline is tricky and a lot can go wrong here. Thats why I usually have this created by a Jenkins plugin which I created (https://github.com/chrisdutz/jenkins-release-plugin). Also it sort of feels like I am doing Ant to Maven migration for the last few years all the time ... for business, in other Apache Project (Mainly Apache Flex) ... and every now and then I come to this point. I still don't really see how losening this restriction would really break something. Every time this issue comes up, I get responses like "don't want to break anything" but I don't quite understand how this would actually break things. Another route would be to extend the versions plugin tob e able to set multiple artifacts versions to given versions. Or last but least to create a new plugin, which I would really like to avoid. Chris -----Ursprüngliche Nachricht----- Von: Robert Scholte [mailto:[email protected]] Gesendet: Freitag, 28. November 2014 18:42 An: Maven Users List Betreff: Re: Problems with the release plugin Op Thu, 27 Nov 2014 14:12:58 +0100 schreef Dutz, Christofer <[email protected]>: > Hi, > > I just ran into a problem I was having a few times now with the > release plugin. This time the usage scenario is different, but the > code needed to be changed is still the same. > > This time I am helping migrate a large set of projects from Ant to > Maven. As this involves a large amount of training the transition is > done project by project. > Currently as a first step all projects are changed to deploy SNAPSHOT > and release versions to Nexus instead of deploying to an Ivy repo. For > this all Ant builds were extended to produce and deploy artifacts > useable by Maven and the Ant builds are configured to use Nexus > instead of Ivy. > > Now whenever a release is done there actually have to be two releases > performed. One Ant and one Maven release. For the Maven part we wanted > to use the default release plugin. For this we are planning on > providing the release and development version for each artifact as > described in this article: > http://maven.apache.org/maven-release/maven-release-plugin/examples/no > n-interactive-release.html For the Ant part we have created an Ant > task that updates the ivy.xml to the correct versions, which > understands the same syntax of providing dev and rel versions as that > of the Maven release plugin. > > Now the problem is that AbstractRewritePomsPhase only seems to process > the version numbers of artifacts that are in the reactor: > > https://github.com/apache/maven-release/blob/trunk/maven-release-manag > er/src/main/java/org/apache/maven/shared/release/phase/AbstractRewrite > PomsPhase.java > > Wouldn't it be possible to leave the version map the way it is, > without filtering anything out? If a user provides the rel version and > the dev version for an artifact I would assume that he actually should > have a reason for doing this. This behaviour is causing quite some > difficulties here. > This is probably the most tricky part. I'd like to keep the process as simple as possible with a minimum of a failing release. Since we only have full control over the versions of the current (multimodule) project, these are safe to map. *If* we allow versions of other dependencies as well, then these should be checked as well, both release and development version. The maven-release-plugin is just too important to allow these kind of manual input where the changes of failure are that big. I've started with the introduction of a VersionPolicy[1] in the maven-release-plugin. It's not yet exposed, so you can't specify your own policies yet. But this would give you the opportunity to select the versions automatically instead of specifying it from cmdline (which is doomed to fail every now and than). So here you could help and see if this concept works for you as well. regards, Robert [1] http://maven.apache.org/maven-release/maven-release-api/apidocs/index.html > I would be glad to assitst in finding a good solution for this, if > there is no chance in getting this changed, we will propably have to > work on a custom version oft he release plugin, which I would really like to > avoid. > > Chris > > -- > > ING-DiBa AG, Frankfurt am Main. Registernummer HRB 7727, > Handelsregister Amtsgericht Frankfurt am Main. Vorstand: Roland > Boekhout (Vorsitzender), Herbert Willius (stellv. 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. > > 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]
