continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Drolshammer <>
Subject Re: [Discussion] Continuum 2.0 Roadmap
Date Sun, 17 Feb 2008 13:35:44 GMT
Maria Odea Ching wrote:
> Anyway, +1 on the things in the wiki. All the ideas are exciting :) As what
> have been mentioned already in the thread, I agree that it would be easier
> and more manageable to implement these plans in milestones not just in one
> blow.

Smaller iterations and more frequent releases is a very good idea. If 
the transition from 1.0.3 to 1.1 had been done in smaller iterations I 
think Continuum would have been a lot more popular today than it is now. 
(Frequent releases seem to be one of the things that attract people to 

> And if Continuum will be switching databases, I'd go with JPA. Comparing my
> experience in using JPA and JPOX, I'd say that it has been more pleasant
> with JPA. I also think switching from Plexus to a different framework would
> attract more contributors as a lot of people outside the Maven community
> aren't really very familiar on how to use Plexus.

If I could choose between Jpox and JPA and Plexus and Spring, I'd chosen 
JPA and Spring in a heartbeat. However, if you haven't got any really 
_need_ for functionality only provided by JPA or Spring/whatever, the 
value added to Continuum compared to the cost of implementation is not 
worth it IMHO.

I also want to address the wish to "attract more contributors". As some 
of you might know, I have developed an extension to Continuum that I now 
call Backward Compatibility Tester [1]. I thus feel that I can give 
feedback with regards to how it is to start developing on Continuum. 
IMHO the most serious showstoppers are

1. I'm unable to run tests that extend AbstractContinuumTest in my IDE 
2. I'm unable to run tests that extend AbstractContinuumTest in my IDE 
3. I'm unable to run tests that extend AbstractContinuumTest in my IDE 

4. Lack of documentation. E.g., I haven't found a single design 
diagram/description that explains how the 30~ modules interact...

5. There are 30 or so modules in the same maven project.
5.1 The build is horribly slow (6min 28secs on a Intel Core2 6300 CPU @ 
1.86GHz with 2GB ram).
5.2 It is hard to grasp the underlaying architecture.
5.3. Are really all these modules needed to check out some code from a 
repository and run mvn clean install?
Yes, I try to suggest that some of the functionality should be moved to 
separate projects. Perhaps a plugin-based architecture is the solution, 
but I think much can be achieved by refactoring to a smaller set of 
libraries that different products can use. (This might be a first step 
towards Continuum with distributed builds.)
Perhaps continuum-model, continuum-xmlrpc or maven-continuum-plugin can 
be split out to separate maven projects?

6. JPOX is buggy, hard to debug and difficult to work with.

[1] (only a prototype, not production ready)

Erik Drolshammer
Sherriff @ #continuum and #maven

View raw message