Thiessen, Todd (Todd) wrote: > > 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. >
I don't think it's necessary for the local developer builds to be pinned to specific versions of dependencies; pinning only needs to happen on commit, probably as part of the CI. So the CI would pull together the latest version of each dependency at that point in time, and make sure the information is included in the artefact. Thiessen, Todd (Todd) wrote: > > 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. > Reading through this thread, I see two unreconcilable processes for managing the build -> release cycle. One involves running builds through CI with no intention of releasing them to production. Call it "progressive delivery", since you're progressively building your code to the point where you're ready to release it. The other approach involves assuming that any build that passes CI will be promoted to the next stage, and may eventually reach production, i.e. "continuous delivery". Although the two approaches are essentially unreconcilable for a given project, I don't see any reason why Maven can't support both. The main obstacle seems to be resistance to the validity of alternative processes. I don't think continuous delivery requires massaging snapshots; personally I think Maven's snapshot concept isn't useful for CD. Each CI build needs to be treated as a release, and dependencies from other teams should only be pulled from builds that have passed CI. Promotion of a build through the pipeline shouldn't involve fiddling with the artefact, but should be managed externally by whatever toolset you're using to manage the pipeline. CD may or may not require modification to Maven and/or plugins to inject the information (at CI) needed to rebuild it. It sounds to me that if the build and its dependencies are all treated as releases rather than snapshots, the information is probably in there. Does anyone have a reason why Maven snapshots would be useful or necessary to a project following CD? Kief > -----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 -- View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3256621.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
