Having tried more or less Ron's prescription, I have to offer a caveat. You spend a lot of time watching the release plugin running.
Frequently, a group of inter-related components has some component that accumulates shared utilities. In my experience, at least, the shared component is very busy -- all the users of it find reasons to change it or add things to it. Call it 'com.mon:common' (groupid com.mon, artifactid common). So, you start out on day 1 with all versions at 1-SNAPSHOT. To try to take Ron's prescription seriously, the first thing you do is run the release plugin on everything. OK, now there's a '1' of each component in your copy of nexus. And now you have to make a decision. Option 1: All the other projects reference com.mon:common:1. Everyone is using the version with the warranty: for the five minutes that elapse before everyone feels the need to make a modification to com.mon:common. Now, each of those people grimaces, and modifies the pom of the thing they are working on to say, '2-SNAPSHOT' for the dependency on com.mon:common. When it all works, they check in their new version of the source of com.mon:common. Now they have to release it, and then update everything to use the new version. And probably collide with other people who just did the same thing. Option 2: All the other projects reference com.mon:common:2-SNAPSHOT. To maximize sanity, assume that *no-one ever deploys a snapshot*. Everyone downloads all the source and builds everything, so that they have a local snapshot. They make whatever changes they need to, and check in as needed. Once per iteration (scrum-speaking), someone does an organized job of releasing everything. As far as I can tell, Option 1 is only practical once the velocity of change slows down to the point where at least some components sit unchanged for a good long time -- that is, for more than one development iteration. It's only useful to 'use a version with a warranty' if that you can use that version, unchanged, for your iteration. If you have to make changes, or use the latest changes in svn, every day, you might as well just be building it yourself and use your local SNAPSHOT. Note that 'automatically releasing and bumping version numbers every night' is here nowhere. It leads to constant churn in the pom files, source control merge conflicts, and other distress. Releasing something, *in my opinion* (and all of this is a matter of *opinion*) only makes sense when that release will have a half-life of at least a week. Every 'release' results in changes to all the poms, plus tagging and bagging in svn. If you want to test packages every night, my suggestion is to test a snapshot, and use the build number plugin to assign a number that is both unique and suitable concise. Further, *do not* publish those snapshots to a repo where developers will download them. That leads to the dreaded 'SNAPSHOT skew screw' and you don't want that. Have the build number plugin capture the svn rev # for the checkout of the tree. That's all you need to be able to repro any test failures, you don't need an svn tag. If the pitfalls and evils of deploying SNAPSHOTs aren't clear to any interested reader, I'd be happy to type up the standard explanation. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
