I think I see two points here. 1. Reproducing a problem on a particular revision. 2. Delivering a CI build to your final customer.
While somewhat related, I think it is important to distinguish these two things in this dicussion. The concept of snapshots I think works extremely well. True, you don't want to be delivering snapshots to a final customer. But this is ok because it really allows you the flexibility to always be working on the trunk. And it allows you to do so without changing your pom everytime you build. Your developer build is the same as your CI with respect to your pom. Imagine trying to have a CI build while always having enough information in the pom to point to an exact version of your dependencies? Lets say I get a feature working in my checkout, and do a build locally before committing. The build would have to point to a fixed version of all my dependencies. If the dependencies change while I am working, they would have to change "on the fly". But of course the formal CI build would also have to ensure it points to the latest fixed version of all dependencies. It would have to modify the pom "on the fly" and it could change to point to a more recent version of a dependency since there is time between when I run the build in my checkout and the time I commit. It just gets very complicated very quickly. I would rather have all revision numbers in all jars. I am against the idea of having an automated process massaging a snapshot and turning it into a release. You simply run the risk of building something that you didn't anticipate. If you want to build a release, build a formal release. This will include ensuring that all of your transtive dependencies are also a formal release. That way you control exactly what revision of what transitive dependencies will be built as a release. Now perhaps we could automate the process of building the formal release of the project and all of its transtive dependencies. But massaging existing snapshots into a release I don't think would be wise. Or maybe there is a completely different kind of architecture here that would allow you to do this. I just don't think that it fits into the current Maven architecture; or any other build management system for that matter. > -----Original Message----- > From: stug23 [mailto:pat.poden...@gmail.com] > Sent: Sunday, November 07, 2010 12:17 PM > To: users@maven.apache.org > Subject: RE: Continuous Delivery and Maven > > > I suspect that there is a reasonable way to adjust the builds in Maven > such > that they robustly support Continuous Delivery. I know that Jason van Zyl > has started looking at CD as well. > > On the Google forum > <http://groups.google.com/group/continuousdelivery/browse_thread/thread/c > 8440681058f2db8> > Chris Hilton commented: > > 3. In my ideal world, I would probably either extend the release > plugin or write a new one with functionality to take a snapshot > artifact and make it a release artifact, which would still introduce > slight changes but pretty mild ones. I thought I had read a feature > request or wish list about this, but can't find it now. > > The current Maven release plugin, as it is, was not designed to handle > the > notion of CD. So it does make sense to tailor this aspect of releasing > Maven > artifacts to better support CD. > > Also a quick examination of the Maven versions plugin shows that it has > facilities to handle updating versions of projects and their > dependencies. > So it looks as if it is more a matter of adjustment of Maven build to > produce a result that aligns with CD than a matter of Maven not being > suitable for CD. I think that the main stumbling block is SNAPSHOTS > because > they inherently are not releasable -- part of the process of releasing > with > the current Maven release plugin is to fail when there are SNAPSHOT > dependencies. > > Another clear requirement for any changes to Maven or its build behavior > is > that the current behavior must be maintained for the many projects that > haven't embraced (or won't embrace) Continuous Delivery. So I imagine a > Maven build's behavior being altered through configuration (or a switch > of > some sort) to comply with the desired behavior inherent in Continuous > Delivery with respect to the release of artifacts. The major difference > would appear to be with the SNAPSHOT dependencies and the Maven release > process. Other aspects of Maven are for the most part already good as > they > are for CD. > > This is an interesting challenge that I am sure is best served by a > thorough > examination by the Maven and CD experts out there. > -- > View this message in context: > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven- > tp3245370p3254121.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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
