continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Thakur <>
Subject Re: [Discussion] Continuum 2.0 Roadmap
Date Fri, 08 Feb 2008 02:31:14 GMT

>> 1-2)    I would like to bring Guice to the mix. I think it is worth 
>> investigating for Continuum 2.0 - WDYT?
> I need a reason to drop the current set of technologies, why is the 
> new set better etc.
My motivations behind this were:
#  leverage Java 5 language and other library features, and enable 
Continuum to do the same.
#  Encourage more contributions by using tools/libraries that have a 
good user base.

>> 3) Builders > Build definitions
>> Just thinking out loud here...
>> Does anyone else see the current Continuum model to be centered 
>> around 'Project'? What do you think about 'Build' or BuildDefinition 
>> being central? You can add one or more Projects to a Build - we don't 
>> need Project Groups, as all we deal with is a Build. Order and 
>> dependency can be imposed on a Build composed of more than one 
>> project. Notifiers are added to a Build and BuildResult(s) produced 
>> for a Build.
> This is way to detailed to be on a roadmap.
Yep, way too detailed for the roadmap but that was just a random 
thought, please ignore it at this stage ;-)

>> 8) Installation
>> Lastly, I think it would nice to have a core Continuum install to be 
>> lean and small with features that can be added by dropping in 
>> relevant JARs (and minimal or no configuration). We can actually try 
>> different options with development releases before finalizing what 
>> should go into the main distro (if at all we break it up) - sounds 
>> reasonable?
> I'm not sure what you're trying to say here. The current way to 
> installing Continuum (unpack, run bin/ is still giving me 
> "wow" when doing demos.
I was just hinting if Continuum dist could be leaner, but again may be 
too early at this point in time
> What I would like to see is talk about the different ways of doing 
> remoting and tool integration (IDEs in particular, but also desktop 
> widgets).
> Overall I think the core of Continuum should be re-though to be more 
> pluggable. In particular a workflow engine should be in the middle of 
> the execution to orchestrate any steps involved with building a 
> project. This is one of the places where people should be able to plug 
> in their own steps and functionality.
> If someone is going down the plugin path, it is essential to me that 
> these plugins can be written in vi inside an existing installation and 
> copied around. This implies to me that we have to support a plugin 
> language like jython, jruby or groovy.
I agree with the possibility supporting multiple plugin languages in the 
long run but just having support for Java based plugins for starters. I 
am not yet sure what all is involved in supporting plugins in other 


View raw message