1. +1 on distributed builds, along with examples on the 2 main use
cases I see for distributed builds:
a. building on many platforms for native builds that need
multiple distributions.
b. distribute the build across many machines to decrease the
latency of building everything.
2. +1 on the docs comment below.
3. As to slicker UI, I'm not sure it's as necessary, and there's
nothing stopping 1.x from getting a better UI. The bigger issues for
me are:
a) better co-ordination of reports/dashboards
b) integrations with various other systems and dashboards and
monitors (mylyn, jira, etc.)
4. Full configuration of the bootstrapping/staging of the build
environment. I'm still experimenting with the current mechanisms, but
I think it still needs work.
5. Apart from distributed builds, I think we need parallel building of
mutually independent projects.
I care less about the underlying technologies because most people
won't be adding osgi or plexus or picocontainer components willy-
nilly. I would replace plexus if it is deficient, but unless there's
a compelling reason to switch, I wouldn't work at it too hard. For
example, if it was based on Tapestry (not a plug, just an example),
then moving to tapestry-ioc would make sense because t5 comes with it,
it's based on that model, and it cleanly integrates with spring for
extension. In that case, however, it's a change for convenience. I'd
be even happier if such a switch of any given subsystem was because of
a solid decision of either defect in the current approach, or
improvement in the new one. Spring makes me a bit woodgy because
while it's an IoC container, it's not really (in my experience) a
great plug-in system. An infrastructure around a plugin lifecycle
would need to be built on or (3rd party) added to spring to make it
really useable that way.
Christian.
On 7-Feb-08, at 21:56 , Rahul Thakur wrote:
Here's my list:
1) Peformance improvements.
2) A slicker User Interface. Ability to let the user work in an
offline mode (Google Gears!) and sync periodically.
3) Good user and developer documentation.
4) Better public APIs (rework Store and Continuum)
Rahul
Napoleon Esmundo C. Ramirez wrote:
Just some thoughts,
I strongly agree to the proposed technology changes, particularly
in the
database, as it will definitely improve the storage performance.
In line
with the objectives to make Continuum a slick CI server, I think
the design
changes is a good move as well. In my opinion, having plugins will
provide
a platform for flexibility and a workflow-type of approach in
managing the
builds.
My proposed features would be the following:
1. Aside from the improvement in the UI, I think a visual
representation of
statistics would be nice. Graphs of the success rates, charts of
project
health, etc. I think Bamboo has it as telemetry.
2. Distributed builds, this has been started before but it was
never used.
I think this would be a strong point in using Continuum if it were
available. Hudson has it, iirc. I think implementing it as a
plugin would
provide more control to it.
Again, just my thoughts.
Cheers!
Nap
On Feb 6, 2008 8:12 AM, Carlos Sanchez<[EMAIL PROTECTED]> wrote:
Some comments
Database vs xml: definitely database. Throwing away the db access
api
(JDO/JPA/...) now that it's already there doesnt make much sense.
Maybe there are implementations that use xml for storage and that's
where you'd need to look if you want file storage
Spring vs Guice vs Plexus: Spring for sure. Big community, lots of
users, documentation, support,... Specially if you want to add JMX
support (can be done really easily just with annotations using
reflection), and thinking in OSGi in the future I'm sure it will be
really easy to integrate Spring and OSGi if it is not already. I'd
start softly, just migrating thing that would require adding
features
to plexus, and move from there.
I agree with Brett on having 1.2, 1.3,... it's good to have a list
of
what you want to do for 2.0 but as it gets done it should be
released
in minor versions.
On Jan 29, 2008 2:34 PM, Emmanuel Venisse<[EMAIL PROTECTED]>
wrote:
Hi
I started a document [1] with my ideas about Continuum 2.
As you can see in this doc, I want to add lot of things in the next
version.
Feel free to comment on it.
[1]
http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion
Emmanuel
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
