> 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.
Ok. I will refocus here. Let me just say that this discussion is inevitable. It is important as the value of CD will help determine if Maven should consider working towards supporting this kind of process. The basic architecture of Maven today does not lend well to it. So we can table it for now. You comments I think took what I am trying to get across very much out of context but *snip* them for now and defer the discussion to a later date. > *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. I don't think that is enough. Using timed snapshots is already not recommended in general; as others have noted they don't persist. But for now lets assume that you configured your environment for them to persist and to use them. The final artifacts and all the meta do not represent what is considered a released artifact. The meta data is different and the artifact names are different. So the release process would have to "massage" the snapshot artifacts to "look" like releases. This will of course invalidate much of the testing done by your CI. When I say meta data here, I am referring to the meta data maven stores about the artifact. This information doesn't appear in the pom. Also if you do this you will be breaking the idea of CI. If your dependencies point to specific time stamp then that build won't be getting the latest version of those dependencies. You'd need some process to constantly update the pom to always point to the latest version of all your dependencies. This I think would be fairly complex as your pom files would be constantly changing, even if you as a developer didn't need to change it. So your process would be something like: 1. Commit code. 2. Fire off CI build that builds using snapshots. (say version 1.0-SNAPSHOT) 3. Fire of CD build. First thing it does is create a release of all transitive dependencies and then the core build (say version 1.0-01). 4. Whether CD build passes or not it has to revert the source back to its CI state (ie: versions abck to 1.0-SNAPSHOT). I think what you would want is to not use snapshots at all. Treat everything as a release and work around that. So instead you'd have something like: 1. Version in all points represents a release. Say 1.0-01 2. Commit code. 3. Build 1.0-01 release. 4. Bump pom to 1.0-02. We use to have guys do something like this sometime ago and it worked fairly well. A little more complicated since they had to script a lot of things themselves but I am sure a lot of this complexity can be hidden in a plugin. They eventually moved to snapshots though as the idea of continually releasing proved to have little value. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
