continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trygve Laugstøl <tryg...@apache.org>
Subject Re: [Discussion] Continuum 2.0 Roadmap
Date Thu, 07 Feb 2008 08:24:13 GMT
Rahul Thakur wrote:
> Hi,
> 
> Great to see version 2.0 discussions kicking off! Thanks for putting the 
> ideas on confluence, Emmanuel. :-)
> 
> Some notes around the ideas outlined on the wiki:
> 1)  Architecture
> Moving to JSE 5 and JPA is a good idea \o/, it been fairly overdue ;-).
> 1-1)    Can you please elaborate a bit on relationships among - 
> services, various types of facades and entities. A concrete example 
> would help.

Annotations is nice, but really isn't what is stopping Continuum from 
moving ahead. Moving to standardized, mature technologies will probably 
be smart in the long run as it is easier to get help and for other to 
contribute.

> 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.

> 2) Database
> I am not hard and fast on any particular JPA provider. If Toplink cuts 
> it, we should go with it. I have been toying around with OpenJPA, but I 
> haven't used Toplink to comment on how both compare. OpenJPA is 
> comprehensively documented and has a good support available on mailing 
> lists. Having said that, JPA providers would ultimately be swap'able 
> under the hood.
> 
> Also, I think we should stick with JPA annotations on model entities 
> instead of using Modello. I hope writing the data access code from 
> scratch implies the current ContinuumStore will be refactored into 
> something which is less verbose than what we have currently, and so 
> would the Continuum interface.

JPA annotations is probably a good idea as you'll get IDE support etc 
from the start.

> 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.

> 4) Remote Builders
> I like this idea, but not sure how the build results will be aggregated 
> from remote builders, but may be that is something that needs some more 
> thought.

This is something that definitely should be at the core of the 2.0 
architecture.

> 5) Plugins
> Is this similar to what AntHill Pro has? Are we going to have a notion 
> of Build lifecycle (and phases) to support this? Is this something that 
> can be borrowed in concept (and possibly implementation) from Maven?

Same as the previous point, +1.

> 6) External Access and UI improvements
> I am +1 for supporting different types of mechanisms to access and 
> control Continuum. Web interface has been the primary interface until 
> now and I totally agree that it needs to be improved to give a better 
> user experience. I welcome the idea of using GWT for this.

GWT vs anything else again way to specific when you're talking roadmap. 
Doing experiments is a good thing, I'm not trying to shoot anything down 
here, but focus needs to stay on *features* and then we can try to find 
a suiting set of *technologies* when/if it comes down to that.

> I am keen to focus more on Reporting as well for this version. As 
> already outlined on the wiki, it would be nice if the reporting can be 
> extended via plugins or some such mechanism.

Reporting is something that definitely can be improved.

> 7) Documentation
> I would like to add and emphasize here on documenting the code itself as 
> we write it. We are not going to get down to user documentation from day 
> one but there will be users in the community who start consuming the 
> code and contributing back as soon as we starting cooking it! :-)
> I would like to propose having Checkstyle to flag undocumented source 
> code in codebase.

More documentation is always useful, yes.

> 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.

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.

--
Trygve

Mime
View raw message