continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Whitlock" <>
Subject Re: Release Management for Maven/Continuum
Date Thu, 24 Aug 2006 23:51:21 GMT
Hi all,
    After talking with Jason I have started on phase 1 of this venture.
Phase 1 is as follows:

1.  Create a model for Maven to use for the release descriptor
2.  Integrate the model into the Maven release plugin

I seems too simple but that should be phase 1.  What this will do
is allow Maven to use a Java object, which can be persisted to a file like
XML, to store the model.  Why is this important?  Once we want to have
Continuum be able to perform the release it is as simple as sending the
release descriptor object to Continuum to do the work and return a status.

Phase 2 will start with Continuum facing things which will get Continuum
capable of performing the release and returning a release status object.
This phase will also be used to update the web interface to be able to
perform releases based on the guidelines Brett and Jason have discussed in
this email.

Phase 3 will be to modify the Maven release plugin model to allow for
Continuum bits to be stored in the model and used to delegate the release
process to Maven.  This process will also involve having Maven handle the
release status object returned.

How does this sound?  It is pretty high level and does not discuss or
outline any of the lower level details.

Take care,


P.S. - This email is the result of Jason and I talking so if I butchered
what was discussed, please let me know Jason.

On 8/24/06, Jan Nielsen <> wrote:
> Sorry for jumping in here but I'm not entirely sure I understand the
> big-picture process you are describing. Is the only difference between a
> "build" and a "release" the presence of meta-data describing what you
> built the release from (and possibly the life-time of that meta-data)?
> If so, one way to implement a "release" is to "tag" everything with some
> release moniker, e.g., "1.0", and then retrieve all these tagged files,
> then build it, and then publish it as your "release 1.0". This has the
> obvious benefit of using the SCM system to track release numbers, but the
> drawback that some SCM systems take along time to perform the tag
> operation and it requires a two step build procedure, tag-and-build, which
> is not the normal build cycle. For releases spanning multiple modules this
> scheme become complex and very broad. (Is the intent of the "prepare" step
> to perform the "tag" SCM operation?) To recover a past release build, you
> then use the SCM to retrieve the "tagged" files - easy enough.
> Another way is denote a release is to capture the meta-data of files in
> the build, and dependent modules, and then check-in this release
> descriptor with the release tag. The drawback to this scheme is obviously
> that the SCM store no longer directly identifies the set of files with an
> explicit release number. But the benefit is that no single "tag" operation
> needs to be done on the entire file set before the build and the built set
> of files is collected after the build operation which can be now be done
> for each build. The release descriptor will then contain the uniquely
> identifying information for all files built, collected after the SCM
> update operation, and all release descriptors of dependent modules. To
> recover a past build, you then use the SCM to get the release descriptor
> and from the release descriptor pull the appropriate POM and files from
> the SCM - this is now a two step procedure, but these two steps could be
> automated.
> As you may have guessed, each of our builds is a "release" which enables
> us after QC completes to define build 12345 as "Release 1.0" (and once the
> release has been defined, you could go back and "tag" each file in the
> build with the release moniker if you really want the SCM to hold this
> information explicitedly).
> I hope I didn't stir the water. Thoughts?
> -Jan
> Jan Nielsen * System Architect * SunGard Higher Education * Tel +1 801 257
> 4155 * Fax +1 801 485 6606 * *
> * 90 South 400 West, Suite 500, Salt Lake City, UT USA
> CONFIDENTIALITY: This email (including any attachments) may contain
> confidential, proprietary and privileged information, and unauthorized
> disclosure or use is prohibited.  If you received this email in error,
> please notify the sender and delete this email from your system. Thank
> you.
> Brett Porter <>
> 08/23/2006 10:37 PM
> Please respond to
> To
> cc
> Subject
> Re: Release Management for Maven/Continuum
> > The summary page shows only a few of the release parameters. So the
> > "Edit" link is there to direct the user to the more detailed
> > release configuration page.  But since we'll be releasing projects
> > one at a time, I guess I can incorporate what you mean into the new
> > white-site.
> Just to be clear - if the single project that is released has
> modules, there will be multiple entries on this page.
> I think it should be a big long form, though, because it would be
> tedious to change individual values project per project when you need
> to edit them like that (unless we get all ajax, but that might be a
> separate UI initiaive)
> >>
> > ok, so this means continuum should remember prepared releases.
> > Should there be a separate release working directory for this?
> > Because a prepared release may get lost after a scheduled build.
> A prepared release is simply a tag in the SCM, I think (you might
> want to double check that that is all release:perform reads back from
> the release properties).
> Basically what wuld happen here, after fleshing out the model, is
> that it would replace the configuration store in the release plugin
> (so you could use Xpp3Reader/Writer to store release.xml instead of
>, and the same thing could be used to store a
> release's information in the database, along with the information here.
> Anyway, maybe I'm going overboard on that, but its something to think
> about.
> - Brett

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message