[Discussion] Continuum 2.0 Roadmap

[Emmanuel Venisse]

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

[rahul.thakur.xdev]

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.
1-2)    I would like to bring Guice to the mix. I think it is worth
investigating for Continuum 2.0 - WDYT?

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.

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.

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.

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?

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.

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.

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.

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?

Thanks,
Rahul




Emmanuel Venisse 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
>
>  

[Gordon Yorke]

TopLink has a large community of users and active forums at both Oracle and Glassfish.  If you are concerned about licensing, Oracle has donated the full TopLink source to the Eclipse Foundation under the Eclipse Persistence Services (EclipseLink) project.  If you have any questions the EclipseLink dev mailing list is well monitored.
--Gordon Yorke

Rahul Thakur wrote:

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.

[jmcconnell]

How important is the database really to things in continuum?

To me it has always seemed somewhat of an annoyance to have to manage and
maintain when so much of things could just be some xml files on disk.  There
isn't a great amount of search functionality in continuum that in my mind
begs a solution where someone could increase performance by tuning some sql
statements.  The largest chunks of historical data we maintain are things
like build results and they could discovered and indexed in memory pretty
easily I could think...

but if we are going to stick with the database then I think the api needs to
definitely take into account a more distributed nature where multiple
continuum instance would feed into a single database...make it so that we
can generate interesting information across mutliple distributed continuum
instances out of that central database.  I would also like to suggest that
we either make use of a jdo impl that provides for lazy loaded objects where
interacting with something like Project and calling a method on it will
automatically populate what you need in your code, or else we implement it
in a wrapper on these object so that the API into the store can be cleaner
then this getProjectsWithEverythingUnderTheSunPopulated() vs
getProjectThatYouAreEnsuredToNotHaveDataYouWantPopulated() methods.

my 2 cents...maybe jpa would help clean this up but I know rahul and emm
were talking about that not too long ago query wise...I think it would be
most excellent to have one method to getProject() out of the store and have
it be useful everywhere and all of the fleshing out of its content managed
behind the scenes.

jesse


On Jan 30, 2008 10:27 AM, Gordon Yorke <gordon.public@...> wrote:

>
> TopLink has a large community of users and active forums at both Oracle
> and
> Glassfish.  If you are concerned about licensing, Oracle has donated the
> full TopLink source to the Eclipse Foundation under the Eclipse
> Persistence
> Services (EclipseLink) project.  If you have any questions the EclipseLink
> dev mailing list is well monitored.
> --Gordon Yorke
>
>
> Rahul Thakur wrote:
> >
> >
> > 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.
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-Discussion--Continuum-2.0-Roadmap-tp15171171p15184536.html
> Sent from the Continuum - Dev mailing list archive at Nabble.com.
>
>

--
jesse mcconnell
jesse.mcconnell@...

[Gordon Yorke]

JPA fully supports 'lazy' loading of relationships.
--Gordon

jmcconnell wrote:

How important is the database really to things in continuum?

but if we are going to stick with the database then I think the api needs to
definitely take into account a more distributed nature where multiple
continuum instance would feed into a single database...make it so that we
can generate interesting information across mutliple distributed continuum
instances out of that central database.  I would also like to suggest that
we either make use of a jdo impl that provides for lazy loaded objects where
interacting with something like Project and calling a method on it will
automatically populate what you need in your code, or else we implement it
in a wrapper on these object so that the API into the store can be cleaner
then this getProjectsWithEverythingUnderTheSunPopulated() vs
getProjectThatYouAreEnsuredToNotHaveDataYouWantPopulated() methods.

my 2 cents...maybe jpa would help clean this up but I know rahul and emm
were talking about that not too long ago query wise...I think it would be
most excellent to have one method to getProject() out of the store and have
it be useful everywhere and all of the fleshing out of its content managed
behind the scenes.

jesse


On Jan 30, 2008 10:27 AM, Gordon Yorke <[e-mail]> wrote:

>
> TopLink has a large community of users and active forums at both Oracle
> and
> Glassfish.  If you are concerned about licensing, Oracle has donated the
> full TopLink source to the Eclipse Foundation under the Eclipse
> Persistence
> Services (EclipseLink) project.  If you have any questions the EclipseLink
> dev mailing list is well monitored.
> --Gordon Yorke
>
>
> Rahul Thakur wrote:
> >
> >
> > 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.
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-Discussion--Continuum-2.0-Roadmap-tp15171171p15184536.html
> Sent from the Continuum - Dev mailing list archive at Nabble.com.
>
>


--
jesse mcconnell
[e-mail]

[Wendy Smoak-3]

On Jan 30, 2008 12:34 PM, Jesse McConnell <jesse.mcconnell@...> wrote:
> How important is the database really to things in continuum?
>
> To me it has always seemed somewhat of an annoyance to have to manage and
> maintain when so much of things could just be some xml files on disk.

Like the General Configuration?? :)

Considering that we dump the database to XML in order to back
up/convert, and then fight with JPOX to assign the correct next
sequence number to get it back *into* the database, I'd be perfectly
happy to just leave the data in XML and plain text.

--
Wendy

[Emmanuel Venisse-2]

On Jan 30, 2008 9:05 AM, Rahul Thakur <rahul.thakur.xdev@...> 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.

All the code will be in some services classes like builder service or entity
modifier service.
Facades will be the "front-end" for a specific technology like an EJB, a web
service or something. The facade will delegate client calls to the service
and doesn't do more.

>
> 1-2)    I would like to bring Guice to the mix. I think it is worth
> investigating for Continuum 2.0 - WDYT?


I don't think. I don't see the interest to look at it for Continuum. We
already use Plexus that works fine, and  if we decide to move to something
else,  it should be  for the interest of the project  and features we don't
have in Continuum. But maybe you have some arguments about Guice.


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


I don't have something to compare too.


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


I'm totally agree.
We must decide too which datas are kept into the database and which datas
will move to some XML files. I think some datas should be stored in XML
files because we don't use them for requests and they are rarely accessed,
like scm files list.
About entities, we need to review the object model because some fields like
scm fields in Project aren't in a good place, they should be in a sub-object
even if we keep the actual db schema.


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


I think the thing we have actually with project group that contains build
definitions/notifiers is similar to your thoughts
We'll can see later if we need to change the actual model.


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


I'll add more text about it


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


I don't know yet, all ideas are welcome about the design

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

yep.


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


I'm agree about the code documentation. Can you add it in the wiki?

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


>
> Thanks,
> Rahul
>

Thanks for your comments,
Emmanuel

>
>
>
>
> Emmanuel Venisse 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
> >
> >
>

[Emmanuel Venisse-2]

On Jan 30, 2008 9:54 PM, Wendy Smoak <wsmoak@...> wrote:

> On Jan 30, 2008 12:34 PM, Jesse McConnell <jesse.mcconnell@...>
> wrote:
> > How important is the database really to things in continuum?
> >
> > To me it has always seemed somewhat of an annoyance to have to manage
> and
> > maintain when so much of things could just be some xml files on disk.
>
> Like the General Configuration?? :)
>
> Considering that we dump the database to XML in order to back
> up/convert, and then fight with JPOX to assign the correct next
> sequence number to get it back *into* the database, I'd be perfectly
> happy to just leave the data in XML and plain text.

I'm agree about XML files but not for all datas. I think that only "static"
datas should be stored  in files but others are used intensively for
requests or for the UI presentation so, in this case, I prefer SQL.
About sequence number issue, it is easy to resolve it with JPA because we
have the hand on all without a big effort.


Emmanuel

[jmcconnell]

>
> >
> > 1-2)    I would like to bring Guice to the mix. I think it is worth
> > investigating for Continuum 2.0 - WDYT?
>
>
> I don't think. I don't see the interest to look at it for Continuum. We
> already use Plexus that works fine, and  if we decide to move to something
> else,  it should be  for the interest of the project  and features we
> don't
> have in Continuum. But maybe you have some arguments about Guice.
>
>

my only comment here is that last I heard plexus was merging with Pico I
think and going into apache as Apache Composer...so while plexus does
everything continuum needs now, there is like a container update/upgrade
somewhere in our future :)

jesse

--
jesse mcconnell
jesse.mcconnell@...

[Emmanuel Venisse-2]

On Jan 31, 2008 11:05 PM, Jesse McConnell <jesse.mcconnell@...> wrote:

> >
> > >
> > > 1-2)    I would like to bring Guice to the mix. I think it is worth
> > > investigating for Continuum 2.0 - WDYT?
> >
> >
> > I don't think. I don't see the interest to look at it for Continuum. We
> > already use Plexus that works fine, and  if we decide to move to
> something
> > else,  it should be  for the interest of the project  and features we
> > don't
> > have in Continuum. But maybe you have some arguments about Guice.
> >
> >
> my only comment here is that last I heard plexus was merging with Pico I
> think and going into apache as Apache Composer...so while plexus does
> everything continuum needs now, there is like a container update/upgrade
> somewhere in our future :)
>

Agree, we won't change if we don't need it.

I'm thinking to Spring because it have lot of good features like transaction
support, remote object instead of EJB... and Plexus/Pico don't have them

Emmanuel

[Rahul Thakur-4]

Jesse McConnell wrote:

>>> 1-2)    I would like to bring Guice to the mix. I think it is worth
>>> investigating for Continuum 2.0 - WDYT?
>>>        
>> I don't think. I don't see the interest to look at it for Continuum. We
>> already use Plexus that works fine, and  if we decide to move to something
>> else,  it should be  for the interest of the project  and features we
>> don't
>> have in Continuum. But maybe you have some arguments about Guice.
>>
>>      

 From what I have seen and used of Guice, its a very tight
implementation that leverages Java 5 Generics and Annotations.
Have a look here for some more:
http://code.google.com/p/google-guice/wiki/SpringComparison

> my only comment here is that last I heard plexus was merging with Pico I
> think and going into apache as Apache Composer...so while plexus does
> everything continuum needs now, there is like a container update/upgrade
> somewhere in our future :)
>
> jesse
>
>    

[rahul.thakur.xdev]

Rahul Thakur wrote:

> Jesse McConnell wrote:
>>>> 1-2)    I would like to bring Guice to the mix. I think it is worth
>>>> investigating for Continuum 2.0 - WDYT?
>>>>        
>>> I don't think. I don't see the interest to look at it for Continuum. We
>>> already use Plexus that works fine, and  if we decide to move to
>>> something
>>> else,  it should be  for the interest of the project  and features we
>>> don't
>>> have in Continuum. But maybe you have some arguments about Guice.
>>>
>>>      
>
> From what I have seen and used of Guice, its a very tight
> implementation that leverages Java 5 Generics and Annotations.
> Have a look here for some more:
> http://code.google.com/p/google-guice/wiki/SpringComparison

Actually, here's a long answer :-)
http://www.jroller.com/Solomon/entry/what_i_like_best_about

>
>> my only comment here is that last I heard plexus was merging with Pico I
>> think and going into apache as Apache Composer...so while plexus does
>> everything continuum needs now, there is like a container update/upgrade
>> somewhere in our future :)
>>
>> jesse
>>
>>    
>
>

[rahul.thakur.xdev]

>> 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.
>>    
>
>
> I'm agree about the code documentation. Can you add it in the wiki?
>  

Added.

[brettporter]

This looks very exciting, and agree with most of the thread that  
follows. I'm just going to reply in summary - most of my thoughts are  
actually non-technical :)

Regarding databases: I don't think xml files are the solution (except  
for the configuration where it makes a lot more sense :) - the data  
needs to be queryable. I think Andy made a good point in his comment  
on the roadmap - we need to look at the actual problems. Here's what I  
think needs to be improved:
- better centralisation of access. The architecture of Continuum  
bleeds JDO decisions all through the code since you access lazy stuff  
for the first time in obscure places.
- I think this might be that the model is too complicated (sorry, my  
fault) - it assumes complex relationships are handled easily. It seems  
to be going ok these days, but I feel it would be hard to modify.
I haven't looked at Rahul's branch yet, but I think we should consider  
a more decoupled database (ie, lookup build results for a project but  
keep them separate in the model to avoid the need to lazyload 90% of  
the time), and more centralised database logic. I would consider JPA  
just because it gives more options in terms of an implementation. It  
is quite easy to use from a development standpoint. But we also need  
to consider what functionality is needed up front - I think high on  
the list needs to be migrations between versions. Also, We are  
probably going to need to store more data in the future, and be able  
to query it (particularly historical datapoints).

On the container: I would prefer to move off Plexus simply because  
it's a moving target and it's a barrier to entry for new developers.

Now, my more general observations. Firstly, the roadmap doesn't appear  
to have any features - these are all technology changes. Some of that  
might be cool and a feature in itself, but I think there needs to be a  
balance between evolution, features, and bugfixing. I would also  
emphasise that features should be creative new things Continuum can do  
(for which we've had plenty of ideas), not just catching up to other  
CI servers :)

I think the first part of the roadmap is key - separating the layers  
out, and basically building Continuum to be lightweight and  
distributed from the ground up. I hope that's the focus of the  
development. Note this also impacts the database as it should store  
much less information on builder machines (it can ship history back to  
the main server).

I also think that supporting plugins is a good idea - it has been a  
huge bonus in other apps and in Maven itself. I'd like to investigate  
using OSGi for this.

But by far the biggest question I have is what happened to 1.2? I  
think Continuum needs to set a target to achieve, but get there in  
gradual steps that at each stage sees a production release. The long  
1.1 cycle really set Continuum back - a lot of it was changing  
features, but there was also a lot of changing technologies :) I don't  
think Continuum will survive another year-and-a-half release cycle. So  
the start could be to break all the actions out (plexus, not webwork)  
into services and add some features, then the next release could  
adjust the database model and add some other features. And as we split  
these things out we make sure they are nicely documented and tested.

That's my thoughts :)

Cheers,
Brett

On 30/01/2008, at 9:34 AM, Emmanuel Venisse 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

[Carlos Sanchez-4]

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

[Napoleon Esmundo Ramirez]

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 <carlos@...> 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 <emmanuel@...> 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
>

[brettporter]

On 06/02/2008, at 1:20 PM, 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.

+1

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

Yeah, though I think we can be creative here - both by allowing  
plugins and by looking into different ways to represent it. I really  
want my sparklines :)

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

I think that actually this needs to be a fundamental part of the  
design - by decentralising the data. The plugin side would be more how  
the resultant data is handled?

- Brett

[Christian Edward Gruber]

Toplink is mentioned, but it's a commercial app, and I don't think  
they'll license it in a way that's compatible (unless they've  
radically changed policies recently).  I'm not a huge hibernate fan,  
but at least its supported.  At least with JPA and decent abstraction,  
you should be able to have more "swapability" though at the O/R-M  
level I find it's rare to get true swapability.

I've been using and supporting spring for a long time, but after doing  
some tapestry work, and re-thinking IoC approaches, I'm moving in  
favor of picocontainer.  Tapestry doesn't use picocontainer but has an  
IoC framework that's got some similar design concepts.  Actually, that  
gets to another point, which is that Tapestry is happy and easy and  
fun (well, T5), and since it comes with an IoC framework that can  
integrate cleanly with Spring if we want that benefit, you can get the  
whole kit together.

The other nice thing about Tapestry, is that several people have made  
"quickstart" projects which include everything Continuum would likely  
use including Spring, spring-acegi, hibernate/jpa, etc.  One could use  
that as a structural basis, and T5 is (currently) built with maven,  
and will at least be deployed to maven repositories in perpetuity.

Christian.


On 5-Feb-08, at 19:12 , Carlos Sanchez 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 <emmanuel@...>  
> 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
>

[Christian Edward Gruber]

Oh, and Tapestry5 is pretty high-performance, in my initial experience.

Christian.

On 5-Feb-08, at 22:12 , Christian Edward Gruber wrote:

> Toplink is mentioned, but it's a commercial app, and I don't think  
> they'll license it in a way that's compatible (unless they've  
> radically changed policies recently).  I'm not a huge hibernate fan,  
> but at least its supported.  At least with JPA and decent  
> abstraction, you should be able to have more "swapability" though at  
> the O/R-M level I find it's rare to get true swapability.
>
> I've been using and supporting spring for a long time, but after  
> doing some tapestry work, and re-thinking IoC approaches, I'm moving  
> in favor of picocontainer.  Tapestry doesn't use picocontainer but  
> has an IoC framework that's got some similar design concepts.  
> Actually, that gets to another point, which is that Tapestry is  
> happy and easy and fun (well, T5), and since it comes with an IoC  
> framework that can integrate cleanly with Spring if we want that  
> benefit, you can get the whole kit together.
>
> The other nice thing about Tapestry, is that several people have  
> made "quickstart" projects which include everything Continuum would  
> likely use including Spring, spring-acegi, hibernate/jpa, etc.  One  
> could use that as a structural basis, and T5 is (currently) built  
> with maven, and will at least be deployed to maven repositories in  
> perpetuity.
>
> Christian.
>
>
> On 5-Feb-08, at 19:12 , Carlos Sanchez 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 <emmanuel@...>  
>> 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
>>
>

[rahul.thakur.xdev]

Good to see C2 discussions picking up! \o/

Re. TopLink
TopLink Essentials is governed by this license:
https://glassfish.dev.java.net/public/CDDLv1.0.html

I am not sure if that license is compatible with our goals or not. Also,
EclipseLink has already been mentioned on this thread earlier.

Rahul

Christian Edward Gruber wrote:

> Toplink is mentioned, but it's a commercial app, and I don't think
> they'll license it in a way that's compatible (unless they've
> radically changed policies recently).  I'm not a huge hibernate fan,
> but at least its supported.  At least with JPA and decent abstraction,
> you should be able to have more "swapability" though at the O/R-M
> level I find it's rare to get true swapability.
>
> I've been using and supporting spring for a long time, but after doing
> some tapestry work, and re-thinking IoC approaches, I'm moving in
> favor of picocontainer.  Tapestry doesn't use picocontainer but has an
> IoC framework that's got some similar design concepts.  Actually, that
> gets to another point, which is that Tapestry is happy and easy and
> fun (well, T5), and since it comes with an IoC framework that can
> integrate cleanly with Spring if we want that benefit, you can get the
> whole kit together.
>
> The other nice thing about Tapestry, is that several people have made
> "quickstart" projects which include everything Continuum would likely
> use including Spring, spring-acegi, hibernate/jpa, etc.  One could use
> that as a structural basis, and T5 is (currently) built with maven,
> and will at least be deployed to maven repositories in perpetuity.
>
> Christian.
>
>
> On 5-Feb-08, at 19:12 , Carlos Sanchez 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 <emmanuel@...> 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
>>
>
>