Global Architecture

Continuum doesn't have actually a really good architecture. The core must be exploded into some services related to entities. To do that, I'd like to see "real" presentation, business, data tiers.

• the presentation tiers will be use for the ajax requests

• the business tiers will be split into some services accessible by one or more facade(s). The facade will be a POJO, an EJB, an RMI object, a web-service...

The connection between the presentation tier and the business tier must be transparent in the code, the facade type will be chosen in the conf, so continuum will can be deploy into one server or exploded on more servers. The POJO facade will be use for installation on servlet containers and of course, EJB on J2EE containers (not sure yet).
To implement this, we have few options:

• move to J2EE 5 with EJB3...

• add some new tools in Plexus like a transparent connector between tiers, annotations tools to manage classes and proxy generators...

• use Spring instead of Plexus because all is already implemented and lot of users know it

Database access

In the actual store, we have few issues with JPox and database mapping:

• long string aren't stored correctly in some database like Oracle due to small length of the Oracle varchar

• we have some issues with relations between objects during update/delete actions of some entities

• we have some memory issues due to lot of datas from entities loaded that we don't really need

For all of that and more, I want to rewrite all the database access from scratch. To do this, I want to use JPA (with OpenJPA or Toplink). I choose JPA instead of JPOX or something else because :

• it is very easy to develop/maintain the data access code

• it is customizable for optimization by query overwrite and some query hints defined externally

• the SQL for the schema generation can be generated for each database, so customizable by users

• it is the new standard that I like and recommend

Personally, I'd prefer Toplink because it is the reference implementation and it is already used by lot of users, I don't know about OpenJPA. We must look at the Toplink license for the compatibility with the ASL.

Builders

The big part that must be reviewed in the actual code is the builder. It isn't extensible or customizable.

Build definitions

Builder must accept more than one build definition by build. In some case like the use of the dashboard plugin, it is necessary to run more than one goal executed with more than one m2 command, so the user will can run one build definition that execute few m2 commands.

Maven 2 builder should alow to run something different that m2, for example ANT or a shell script. It is necessary to support it because it is required to run few commands before or after the build. Some projects need to do some actions in the build that is external to the POM

Project dependencies support

To support correctly ANT and Shell projects, we must allow users to add dependencies on projects linked to some other projects managed by Continuum. Of course, if projects doesn't know where are installed new artifacts, they won't can use this feature.
To manage dependencies, we'll can use a m2 POM.

Remote builders

Builders will can be installed on some remote machines, a continuum manager will send actions to run to builders. An action can be something to run on all builders, on some of them or eventually only to an available builder if we don't want to run more than one build. Actions can be sent with JMS and builders will can apply some filters if they don't want to receive all actions. With that, we'll can do some parallel builds but the dependency tree must be respected for the build order. To work correctly with dependencies, each builders must use a central local repository. Maybe we can use an internal Archiva.

With Continuum builders configured to receive all commands, users will can run multi-platform build for each build definition execution
With Continuum builders configured to receive only some project types, users will can use a different builder by project group. In this case, the build of all projects will be done quickly because commands are balanced on few servers.
With Continuum builders configured to build something when it is available, users will can installed few builders on several machine to balance the charge. In this case, it will be possible to run some parallel builds.

When the builder work will be done, a message will be sent to the manager to notify the end of the process.

With JMS used for the communication, we'll can add some listeners to create reports/statistics, log some informations...

SCM

We support already the majority of SCM tools, but we always have few issues on them because users have a specific SCM configuration or they want to use some specific parameter for the SCM connection and command lines.
I want to allow users to manage the SCM command used to checkout/update the project, so if they don't like the actual provider, they will can use their own commands. And with this feature, all SCM not supported yet by Maven-SCM will be supported by Continuum.

Plugins

To allow users to customize the build, we must implement the support of plugins. Each plugin will can be plugged where the users want to add it in the process. A plugin will can be activated for all builds on the instance, a project group or a project. A plugin will can be added/removed without to restart Continuum

New builders

I think it would be good to support .Net projects without to use a Shell project. Probably with NMaven.

Configuration

For the configuration, we'll can configure Continuum in few ways.

File configuration

Actually, the configuration is in some files. The big one is application.xml with lot of things that users don't want to see or exceptionally. We must move all the user configuration in one or more "sources" independent of the component definition and easy to understand by users. Sources can be XML files, properties files or something else.

UI configuration

For the majority, maybe all, of configurable parameters, the users will can modify it from the user interface. Even the log configuration must be configurable dynamically and without reboot, so the users will can change the log level globally or on a specific package.

Installer

To pre-configure Continuum, we have actually a first page to configure some fields, I don't think it is enough because users must have the possibility to configure more and necessary parameters like the SMTP server.
Maybe it would be good to create an installer to configure some part. I don't think at an executable installer like script or binary file but with a web UI. The user will can access to the conf part with an url like this:
http://server.name:port/continuum/install

JMX

With all the conf possibility described above, we'll have all in place to configure what we want so it will be easy to add JMX extension to manage the configuration

External Access

Continuum connection types mustn't be limited, I want to support GWT/AJAX, web services (SOAP/WSDL), XFIRE, JMX, JMS, scripts... To do that, the maximum of the logic must be in the services and not in the "client".
User interface
Users aren't really happy with the actual UI in Continuum because pages aren't shown quickly in some case. I'm sure we must add some dynamic part with AJAX features.
To do this, my preference would be for GWT because it is very easy to use, full java and the code to write is similar to something wrote with Swing or SWT.
An other thing that would be great for users would be the possibility to allow to customize the UI.
The last thing is the possibility to create some reports (text and graphical) or to export some data. We won't implement lot of differents reports (I don't know which for the moment) but the reports list must be customizable and extensible with a plugin mechanism.

Monitoring

Actually, it isn't easy to monitor a Continuum instance and some things aren't possible to do without to modify the code.
We must add some JMX Mbeans to manage some Continuum parts (if possible all), like memory, nb projects, nb project groups, build queue, log level...

Installation

For installation, users will can choose between few archive's installation. An all-in-one archive or archives by roles (UI, manager, builder...)

Documentation

WE MUST HAVE A PROFESSIONAL DOCUMENTATION!!!! Each public part must be documented with explanations, screen copies, samples...For something that a user want to know and available in Continuum, the only response should be RTFM.
It is very important to grow our community.

We need to extend this idea to our codebase and ensure that sources are well documented. 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! We should have Checkstyle in place to flag undocumented source code in codebase.