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
Hudson...)
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
(IntelliJ)
2. I'm unable to run tests that extend AbstractContinuumTest in my IDE
(IntelliJ)
3. I'm unable to run tests that extend AbstractContinuumTest in my IDE
(IntelliJ)
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] https://bct.dev.java.net/ (only a prototype, not production ready)
--
Regards
Erik Drolshammer
Sherriff @ #continuum and #maven
