What you're proposing is indeed interesting. But you do seem to pick and choose what you want (reproducibility) and what you can dispense with (tags and branches).
I'm just saying, that as a practical matter, we can today solve your problem without the need for a new plugin. Reproducible, and Auditable. I can look at anything directly, even in Prod, and make the leap all the way to SVN without a single cross reference or lookup because we put all that meta-data in the manifest, just not in the POM (in your scenario, in ours the POM has everything listed as a version though so we don't face the SNAPSHOT issue). You want to be able to Audit but eschew documentation like a Site reports? Again seems sort of cake-and-eat-it-too to me. Are you managing Technical Debt at all? Are you tracking who consumes what so you can do an impact analysis later? ________________________________ 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:j...@jezhumble.net] Sent: Monday, November 08, 2010 12:46 PM To: users@maven.apache.org Subject: Re: Continuous Delivery and Maven 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-146769 ml-node+5194-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-tp32453 > 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32 > 45370?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%2B32553 > 82-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%2B325 > > 53 > > 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-tp324 > > 53<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp > > 32453?by-user=t> > > 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp > > 32<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp > > 32?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=un > > su<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=unsu > > bs<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsu > > bs&by-user=t> > > &by-user=t> > > cribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwt > > MT > > 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-tp324 > > 53<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp > > 32453?by-user=t> > > 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp > > 32<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp > > 32?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-tp324 > > 53<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp > > 32453?by-user=t> 70p3255382.html To unsubscribe from Continuous > > Delivery and Maven, click > here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsu > bs<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs > &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 > 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32 > 45370?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-tp32453 > 70p3255434.html To unsubscribe from Continuous Delivery and Maven, > click here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs 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 p3255456.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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
