I integrate a similar process in continuum :
http://jira.codehaus.org/browse/CONTINUUM-1633
I'm still working on it.
Benoit
Ken Liu wrote:
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]
