continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: Release Management for Maven/Continuum
Date Thu, 24 Aug 2006 02:05:18 GMT
> The original proposal was web services based, but the entire  
> process occurring from Continuum is definitely useful. I think the  
> concrete drivers are:

Right, so like other stuff there is a backend service, and it is  
exposed in the same way to both a web interface and an xmlrpc client,  
but neither depend on the other?

> 1) release:prepare from the CLI with the release plugin and pushing  
> a release descriptor to Continuum. Then using the Continuum Web UI  
> to perform the release.
> 2) talking to continuum via web services from an IDE to do the  
> release:prepare. Then using the Continuum Web UI to perform the  
> release.
> 3) talking to continuum via web services from an IDE to do both the  
> release:prepare and release:perform.
> 4) the case noted above
> The the WEB UI needs to cleanly account for the separation so that  
> the perform is not tied to the preparation being done in the web ui.

yes, good idea.

> - flesh out the release descriptor which is used for a release

yep, that's what I was referring to when I mention "model".

> - flesh out the release manager component and it can just delegate  
> to the release plugin i suppose though separating a release manager  
> component as has been discussed with Jeremy I think would be a good  
> thing to do.

Is this the one in continuum that handles the backend of this  
service, or are you referring to pulling all the code out of the  
release plugin?

> For a multi module build when would you not use the parent? If you  
> wanted a specific component that could be recorded in the release  
> descriptor.

I think you'd always want the parent, but since we have no notion of  
the association in Continuum I'm just wondering how it gets handled.

> A release build is different then what Continuum is typically doing  
> so some separation I think would be wise so that in the UI release  
> specific builds could be identified so possibly a separate queue  
> with some different parameters so that release builds can't be  
> interfered with.

I'm not sure what you mean here, we generally need builds to be  
separate and not interfered with (for example, when we start building  
on two different JDKs on the same instance we'll want to make sure  
they don't conflict - I view that as the same thing)

> I think we should think about this now instead of hacking out  
> something. Jeremy and Edwin seem to have some time so let's address  
> all the points outlined above. Have some feedback on design, which  
> shouldn't take long, and then implement.

+1 to design first.

I'm not sure we need to worry about build queues in this iteration,  
though. That could get right down into the continuum internals.  
Anyway, I'll leave that up to Edwin and Jeremy.

> I think as long as all the design, which I'm sure both Jeremy and  
> Edwin will contribute to, is out on the table and we all agree then  
> they can work out the implementation. I think as they are both  
> relatively new contributors this is the best course forward.


- Brett

View raw message