Right - but I don't want to rely on the build logs or the site report, I want the bill of materials in an easily accessible and simple format that Maven itself can understand - for example in the pom file associated with the snapshot.
In particular, I want to be able to point the Maven release plug-in at the snapshot's pom and run a command which does all the kind of tagging stuff that the release plug-in does, but that doesn't need to reproduce the binary (except to verify that it's identical to the snapshot). I'd also want to be able to create the site report automatically from the snapshot's pom. I don't ever need to re-produce it because I have it and am managing the > binary Except that I do want to keep the ability to blow away the binaries and know I can re-create them, especially when I'm running multiple builds per day. More importantly, it's essential for auditing purposes that we can trace back from any given binary to the exact versions in version control that it and all its build-time dependencies came from. On 8 November 2010 09:34, Yanko, Curtis [via Maven] < ml-node+3255434-1467695194-143...@n5.nabble.com<ml-node%2b3255434-1467695194-143...@n5.nabble.com> > wrote: > Thanks, > > I did manage to find it too. Not sure I follow his logic though. > > "One of the things I like about snapshots is it just simply means > "latest". Though the thing about timestamped snapshots is that they > aren't guaranteed to exist (the repository is not typically assumed to > be reliable), and they aren't 100% reproducible (the timestamp offset > includes the time it took to build the artifact and all the artifacts > before it, meaning there's no way to know exactly what point in time the > build came from). Even if one could find the correct timestamp to check > out from to get the same binary, whatever subsystem creates the > timestamp on upload (wagon?) probably doesn't like being told what to > call the snapshot." > > If I build a SNAPSHOT and deploy it to an internal Maven Repo it will be > given a unique identifier based on a time stamp (repo configured to do > this). Why is that not guaranteed to exist or be reliable? And at the > moment I build A the build log will tell me exactly which SNAPSHOT we > received. I don't ever need to re-produce it because I have it and am > managing the binary but... I can crack it open and see exactly which SCC > revision was used and which path within the SCC it came from (because we > bake that info into everything we build). So I can reproduce it in a > pinch. What's also missing from the conversation is the final assembly > where A,B and C get put together for deployment which is also managed as > a binary and represents the bill-of-materials. And of course my Maven > Site report for A would have documented which B & C I had too. > > ________________________________ > > Curt Yanko | Continuous Integration Services | UnitedHealth Group IT > Making IT Happen, one build at a time, 600 times a day > > -----Original Message----- > From: jhumble [mailto:[hidden > email]<http://user/SendEmail.jtp?type=node&node=3255434&i=0>] > > Sent: Monday, November 08, 2010 12:11 PM > To: [hidden email] <http://user/SendEmail.jtp?type=node&node=3255434&i=1> > Subject: Re: Continuous Delivery and Maven > > > Hi Curt - it was this one: > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370?by-user=t> > p3254439.html > > On 8 November 2010 09:07, Yanko, Curtis [via Maven] < > [hidden email] > <http://user/SendEmail.jtp?type=node&node=3255434&i=2><ml-node%2B3255382-1751046 > > [hidden email] <http://user/SendEmail.jtp?type=node&node=3255434&i=3>> > > wrote: > > > > > I didn't see a reply from a Brian. What answer did he provided that > > answered your question? > > > > ________________________________ > > > > Curt Yanko | Continuous Integration Services | UnitedHealth Group IT > > Making IT Happen, one build at a time, 600 times a day > > > > -----Original Message----- > > From: jhumble [mailto:[hidden > > email]<http://user/SendEmail.jtp?type=node&node=3255382&i=0>] > > > > Sent: Monday, November 08, 2010 11:58 AM > > To: [hidden email] > > <http://user/SendEmail.jtp?type=node&node=3255382&i=1> > > Subject: Re: Continuous Delivery and Maven > > > > > > Todd, I have read all of your posts and I have come to the conclusion > > that you're missing the point of CD. I was really hoping to avoid an > > argument about process, because I just want to work out what needs to > > be done to Maven to make it support CD, and that's already a big > > enough discussion for one thread. However since the thread has > > (perhaps > > inevitably) been taken over by a discussion about what continuous > > delivery is, I will add my 1c. In any case I think I have what I need > > from the discussion with Brian. > > > > With CD, the software is *always* production ready, right from the > > start of the project. Any work of any kind that doesn't result in a > > deployable build is waste. > > > > If you are at the start of a release, your product owner will have a > > good > > > idea of how much content needs to get to the customer to fullfill > > > that > > > > > release. Doing CD through the entire lifecycle is largely a waste > > IMHO. > > > > > > Wrong. In fact, it's the opposite - any work that doesn't keep the > > software in a deployable, releasable state is waste, because you can't > > > know whether or not the work you have done is actually useful, or even > > > whether it keeps the software working. And you can't know whether or > > not the software is working - i.e. whether or not the build can be > > deployed > > - until it has passed end-to-end acceptance tests under realistic > > loads in a production-like environment. > > > > I am fine with you using the process you describe. If it works for > > you, that's great. But please don't call it continuous delivery - it > isn't. > > > > > Now, assuming we are working in a cd process, the crucial thing is > > that we don't waste any cycles creating a build that couldn't be > > released. We then take this binary and put it through the rest of the > > deployment pipeline (or build life or whatever you want to call it). > > But crucially, we don't want to recreate the binary later on. If you > > want more detail on the mechanics of how it works, you can read the > > free chapter from my book here: > > http://www.informit.com/articles/article.aspx?p=1621865 > > > > *What I want from Maven* > > *===================* > > > > We want the simplicity of snapshots with the traceability of proper > > releases. So I think from what Brian said, I'd like the the Maven > > snapshot build process to create enough metadata in the pom file such > > that when you ran the release plugin, it wouldn't be necessary for it > > to rebuild the artifact - it could just do the various bits of tagging > > > and metadata creation using the information in the pom associated with > > > the snapshot. We might also want the release plugin to try and > > recreate the binary using its process and verify the md5 is the same > > as the md5 of the snapshot. > > > > If anybody has any feedback on this hypothesis, I'd be very grateful. > > > > Thanks, > > > > Jez. > > > > On 8 November 2010 08:49, Thiessen, Todd (Todd) [via Maven] < [hidden > > email] > > <http://user/SendEmail.jtp?type=node&node=3255382&i=2><ml-node%2B32553 > > 36-196234 > > > > [hidden email] <http://user/SendEmail.jtp?type=node&node=3255382&i=3>> > > > wrote: > > > > > > I'm thinking tha Ci wouldn't be affected at all, CD still requires > > > > > Ci as a quality metric preventing deployment to the customer. > > > > > > I am curious to see that. Or how it would work. How do you put in > > > fixed release numbers into a CD build and then switch back to CI > > > building? And I can only imagine it being quite complex. > > > > > > The only thing I can think of is something like: > > > > > > 1. CI build produces 1.0-SNAPSHOT > > > 2. CD build produces 1.0-01 > > > 3. CD build reverts source back to 1.0-SNAPSHOT 4. Repeat > > > > > > > > > -------------------------------------------------------------------- > > > - > > > To unsubscribe, e-mail: [hidden > > email]<http://user/SendEmail.jtp?type=node&node=3255336&i=0> > > > For additional commands, e-mail: [hidden > > email]<http://user/SendEmail.jtp?type=node&node=3255336&i=1> > > > > > > > > > > > > ------------------------------ > > > View message @ > > > > > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453?by-user=t> > > 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32?by-user=t> > > 45370?by-user=t> > > p3255336.html > > > To unsubscribe from Continuous Delivery and Maven, click > > here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsu<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsu&by-user=t> > > bs<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs&by-user=t> > > &by-user=t> > > cribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMT > > g4 > > MjM1NzMyNA==>. > > > > > > > > > > > > > > > -- > > Jez Humble > > Co-author, *Continuous Delivery <http://continuousdelivery.com/>* > > http://continuousdelivery.com/ http://jezhumble.net/ > > > > -- > > View this message in context: > > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453?by-user=t> > > 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32?by-user=t> > > 45370?by-user=t> > > p3255361.html > > Sent from the Maven - Users mailing list archive at Nabble.com. > > > > 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: [hidden > > email]<http://user/SendEmail.jtp?type=node&node=3255382&i=4> > > For additional commands, e-mail: [hidden > > email]<http://user/SendEmail.jtp?type=node&node=3255382&i=5> > > > > > > > > ------------------------------ > > View message @ > > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453?by-user=t> > > 70p3255382.html To unsubscribe from Continuous Delivery and Maven, > > click > here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs&by-user=t> > cribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4 > MjM1NzMyNA==>. > > > > > > > > > -- > Jez Humble > Co-author, *Continuous Delivery <http://continuousdelivery.com/>* > http://continuousdelivery.com/ http://jezhumble.net/ > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370?by-user=t> > p3255387.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > 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: [hidden > email]<http://user/SendEmail.jtp?type=node&node=3255434&i=4> > For additional commands, e-mail: [hidden > email]<http://user/SendEmail.jtp?type=node&node=3255434&i=5> > > > > ------------------------------ > View message @ > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255434.html > To unsubscribe from Continuous Delivery and Maven, click > here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4MjM1NzMyNA==>. > > > -- Jez Humble Co-author, *Continuous Delivery <http://continuousdelivery.com/>* http://continuousdelivery.com/ http://jezhumble.net/ -- View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255456.html Sent from the Maven - Users mailing list archive at Nabble.com.
