<snipped>
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.
<snipped>
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 ;-)
<snipped>
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/plexus.sh) 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).
+1
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.
+1
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
languages.
Rahul
