This is a great question...I have wondered the same thing myself. I am working on a complex project that involves simultaneously releasing 6 ears. The whole build consists of 25+ maven projects (not counting modules) that are built and released together (relax, many of them are purely assemblies). The dependency tree between all of these projects is at least 5 deep.
The way we have solved the problem is to always declare SNAPSHOT dependencies (for internal dependencies). At release time, there is a script that tags the trunk, checks out the tag, updates the pom versions, updates the scm path, updates the dependency versions (changes the SNAPSHOTs to released numbers), then commits the changes and builds the release. This is basically the same as what the release-plugin does. The script does this once for each project in the correct dependency order. The script is driven by a yml file that is the metadata for the "super build" - it contains the list of projects, svn locations, and target version numbers, and dependencies between projects. The script is around 200 lines of ruby code. The script is run manually, which is ok since we do this "official release" only once every few weeks. (Each individual project is built in Continuum during normal development.) I justified the cost/time of developing these scripts to my manager by explaining that it took me around two days in the beginning to do the entire build, now it takes about two hours (some artifacts take a long time to run the unit tests) from start to finish. I spent a little bit of time before each release working on the script so now there is a net cost savings :) AFAIK, there is no easy way to do this. I suspect many organizations don't do anything so complex and others do not attempt to _simultaneously_ release so many projects, so the cost of releasing is spread out, and is not noticed. Ken On 5/31/08, Stephen Connolly <[EMAIL PROTECTED]> wrote: > > We have a four uber project set of releases. > > We use scripts to check out the latest released pom.xml for each from svn, > pull out the version number, step back if it's a -SNAPSHOT, update our > module's dependencies to this version, run maven with the integration tests > and check in the updated pom.xml if the tests pass before doing mvn > release:prepare release:perform -B > > This is set up as a number of release jobs in Hudson. > > Just kick off a build and you get the release when it's all done, or an > email telling you what broke... > > I would like to do a bit more work and make it keep trying less new > versions > of the dependency until it falls back to the one it started with... but > that's getting too fancy... the script is currently only 100 or so lines > long > > -Stephen > > On Fri, May 30, 2008 at 9:12 AM, Bracewell, Robert <[EMAIL PROTECTED]> > wrote: > > > In our organization it depends on the project but I have projects that > > release twice a week internally. Other groups or projects that are > > reliant on such artifacts can then decide as and when they want to > > depend on the new artifacts that were deployed. > > > > -----Original Message----- > > From: Geoffrey Wiseman [mailto:[EMAIL PROTECTED] > > Sent: 30 May 2008 03:35 > > To: Maven Users List > > Subject: Re: How to better manage cascading releases > > > > On Thu, May 29, 2008 at 6:39 PM, Michael McCallum <[EMAIL PROTECTED]> > > wrote: > > > > > release early release often... we don't use snapshot dependencies and > > > release > > > artifacts early. So if you are working on one of the 13 dependent > > libraries > > > as soon as you - the dev - is happy the change is ready for use then > > you > > > release it. why leave it as a snapshot? If the change would break > > anything > > > useing it we bump the major version up so its not pulled in until > > > downstream > > > users are ready. > > > > > > if you use version ranges and manage codelines by major version then > > you > > > can > > > easily have the trunk of a project being actively developed and > > released > > > without pulling it into a deliverable. > > > > > > Hmm, interesting perspective. > > > > I still find it takes an hour or two to pull off a release, between the > > dry-run, the actual prepare and the perform -- do you find that cost > > goes > > down if you release a lot, or have tricks for reducing the cost of > > releasing? > > > > - Geoffrey > > -- > > Geoffrey Wiseman > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
