On 9 November 2010 14:10, Thiessen, Todd (Todd) <[email protected]> wrote: > Hey Stephen. I read through your idea a little more closely and I like it. > > The only thing I think it is missing is the ability to use snapshots as > dependencies. That is a very powerful feature of maven that I don't think > you'd want to lose if your using CD.
Well I regard that the project being delivered can only have internal -SNAPSHOT dependencies, all external (to the reactor) dependencies should be release dependencies. One of the things I have wanted to do with v-m-p is to hack around version ranges... for example... if we develop using <dependency> <groupId>foo</groupId> <artifactId>bar</artifactId> <version>[1.0,2.0)</version> </dependency> when we run the preparation goals in release:prepare, we have the opertunity to modify the pom and have that modified pom checked in, so there is nothing stopping us from resolving the range, e.g. <dependency> <groupId>foo</groupId> <artifactId>bar</artifactId> <version>1.1.3</version> </dependency> and now the tag is a locked down reproducible build.... but the developer is stuck with the locked down version... so, if somehow we can tweak things... stick in a comment... or better yet an XML PI <dependency> <groupId>foo</groupId> <artifactId>bar</artifactId> <version>1.1.3</version> <?org.codehaus.mojo:versions-maven-plugin range="[1.0,2.0)"?> </dependency> then all we need is a postReleaseGoals added to release:prepare and we can have v-m-p put the version ranges back in... Which would give you repeatable releases and bleeding edge dependencies... but only released dependencies. The problem with -SNAPSHOTs is that they can be deployed without having passed testing. MRM staging support is really about having atomic releases of multi-module artifacts, e.g. make sure they either all get deployed or none get deployed. -Stephen > > It is almost like you'd want a mode in Maven. Say you had some kind of flag > that said "Continuous Delivery" mode. In this mode, you would only use > release repositories when deploying artifacts or downloading artifacts. > Nothing would ever get built as a snapshot, even if your pom has snapshot > versions. In CD mode, you always use the latest release artifact of your > dependencies. You could never pull artifacts from a snapshot repository in > this mode. > > So, for example lets my project's version iss 1.0-SNAPSHOT. When I do: > > mvn deploy > > it would deploy release 1.0-0001 to the release repo. > > If my project had any snapshot dependencies, it wouldn't have to checkout and > rebuild these. Those dependencies would also have to be in "CD mode" and all > artifacts would have to be to the release repo. So if my project has a > dependency on some artifact with version: > > 3.2-SNAPSHOT > > while in CD mode, maven would query the release repo, find the latest release > artifact (say 3.2-0122) and use that. > > This would of course fill up your release repo but I think you would need to > think of a release repo a little differently if your doing CD. > >> -----Original Message----- >> From: Stephen Connolly [mailto:[email protected]] >> Sent: Tuesday, November 09, 2010 4:24 AM >> To: Maven Users List >> Subject: Re: Continuous Delivery and Maven >> >> 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 <[email protected]> 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- >> tp3245370p3255592.html >> > Sent from the Maven - Users mailing list archive at Nabble.com. >> > >> > --------------------------------------------------------------------- >> > 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] > > > --------------------------------------------------------------------- > 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]
