I though the idea we talked about was to re-write the POM that get's packaged with the actual version used from a version range?
________________________________ Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time, 600 times a day > -----Original Message----- > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > Sent: Wednesday, November 24, 2010 1:28 PM > To: Maven Users List > Subject: Re: Continuous Delivery and Maven > > http://mojo.codehaus.org/ship-maven-plugin > > Let me know what you think? > > -stephen > > On 9 November 2010 09:24, Stephen Connolly > <stephen.alan.conno...@gmail.com>wrote: > > > I think some of the issues are around missuse of Maven. > > > > Maven is a build tool, use it to do your build. > > > > CD needs a separate layer above Maven to do the > deployment... now one > > could use maven plugins to provide that layer, but there are two > > issues I see: > > > > 1. the maven lifecycle does not include the phases you require > > > > 2. inbetween invokations of maven, we have no means to share state > > > > so lets say for #1 we add a phase of "ship"... we'd have > the standard > > lifecycle something like > > > > validate -> ... -> compile -> ... -> test -> ... -> package > -> ... -> > > verify -> install -> deploy -> ship > > > > that would allow us to bind our CD steps to the "ship" > phase... ok, so > > people would have to get used to the fact that Maven uses > "deploy" to > > mean "copy artifact to remote maven repo" and not the CD meaning of > > deploy... but people can "Just Get Over It(TM)" > > > > that allows any build to just go > > > > mvn clean ship > > > > and away we go... except that we would be dealing with -SNAPSHOTs... > > > > so to correct for that we would change the release goals using the > > release plugin to be "ship" in place of deploy... to gain speed (at > > the expense of better tested releases), we could even modify the > > preparation goals using the release plugin to be just > "clean validate" > > and not "clean verify" > > > > then > > > > mvn release:prepare > > > > would be quick > > > > mvn release:perform > > > > would do the CD > > > > Hmmmm... most of this is actually fine for CD, and we don't even > > really need the "ship" phase as we could just bind to the > deploy phase > > using the release profile to ensure that it only takes > place during a > > release... > > > > The down side is we have no way to roll-back easily.... > > > > e.g. we've just released 2.1.5652 but we have egg on our > face due to > > an automated QA test that is giving a false pass... we have > no way to > > revert back to 2.1.5651 except: > > A. to revert the commits and roll a new release B. put in the > > 2.1.5651 artifact by hand > > > > we can check-out the tag for 2.1.5651 and run "mvn ship -DskipTests" > > or "mvn deploy -Prelease -DskipTests" depending on whether > we actually > > got the "ship" phase into the standard lifecycle or whether we just > > used the release profile to bind to the deploy phase.... but at the > > end of the day, that would be rebuilding the binaries... > which (with a > > strict QA hat on) invalidates testing... > > > > I think what you need to do is have a maven-ship-plugin or a > > ship-maven-plugin that works a little like this: > > > > it takes a parameter shipVersion which by default evaluates the > > property shipVersion, but if that property is not defines then > > defaults to ${project.version} > > > > The m-s-p then resolves the shipVersion of the project artifact and > > passes that file onto a ship script... > > > > so if I have a war project foo:bar:1.0-SNAPSHOT:war > > > > mvn ship:ship -DshipVersion=1.0.56 > > > > will redeploy the old version 1.0.56 > > > > mvn package ship:ship > > > > will build the current source code and ship that > > > > mvn ship:ship > > > > will resolve the latest 1.0-SNAPSHOT from the local/remote > repos and > > ship that > > > > we could add a parameter allowSnapshots that will default > to false in > > order to prevent accidental deployment of non-releases > > > > and if you are doing CD you can bind ship:ship to the > deploy phase in > > your release profile. > > > > I think I'll knock something together @mojo to help with this > > > > On 8 November 2010 19:20, stug23 <pat.poden...@gmail.com> wrote: > > > > > > We need to figure out how to best leverage Maven (keeping in mind > > > its > > process > > > and practices) in a Continuous Delivery solution. I like the > > > conversation around this topic and also see that there is > this other > > > discussion about > > the > > > meaning of CD versus CI. > > > > > > From the comments so far, there has been a fair amount of > discussion > > about > > > how to use SNAPSHOTs as if they were something that they aren't. > > > Namely retaining SNAPSHOTs all the way through release, possibly > > > mutating the metadata to make the builds products look > like released > > > artifacts instead > > of > > > SNAPSHOTs without having to rebuild the binaries. Since a > SNAPSHOT > > > works well for a "work in progress" and not for a "thing > I want to > > > keep", maybe > > a > > > different approach would work better. > > > > > > Maybe it would make more sense to just burn lots of > version numbers > > > (e.g, > > > 3.5.1099) and always release with a new yet-to-be-defined Maven > > > release plugin that reflects the processes involved with > CD. If the > > > concern is > > disk > > > usage or inefficiency, perhaps some automation can make this more > > > manageable? > > > > > > I would be interested in inputs on this topic from the Maven > > > founders if they are following this thread. > > > -- > > > View this message in context: > > > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453 > > 70p3255592.html > > > Sent from the Maven - Users mailing list archive at Nabble.com. > > > > > > > -------------------------------------------------------------------- > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
