Because I thought we want to keep the version ranges in SCC for developers and just package the POM fully versioned for that build.
________________________________ 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:[email protected]] Sent: Tuesday, November 09, 2010 11:05 AM To: Maven Users List Subject: Re: Continuous Delivery and Maven Why bother... the checkin is automatic and actually a good thing IMHO On 9 November 2010 15:37, Yanko, Curtis <[email protected]> wrote: > What if you just avoid the check in? Only package the pom and deploy the jar? > > > ________________________________ > > 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:[email protected]] > Sent: Tuesday, November 09, 2010 9:32 AM > To: Maven Users List > Subject: Re: Continuous Delivery and Maven > > 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] > > > 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: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] 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: [email protected] For additional commands, e-mail: [email protected]
