You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@continuum.apache.org by Emmanuel Venisse <em...@venisse.net> on 2008/01/29 23:34:59 UTC
[Discussion] Continuum 2.0 Roadmap
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
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
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
>>
>>
>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
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
>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Emmanuel Venisse <em...@gmail.com>.
On Jan 31, 2008 11:05 PM, Jesse McConnell <je...@gmail.com> 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
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Jesse McConnell <je...@gmail.com>.
>
> >
> > 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@gmail.com
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
>> 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.
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Emmanuel Venisse <em...@gmail.com>.
On Jan 30, 2008 9:05 AM, Rahul Thakur <ra...@gmail.com> 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
> >
> >
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Trygve Laugstøl <tr...@apache.org>.
Rahul Thakur wrote:
>
> <snipped>
>>> 1-2) I would like to bring Guice to the mix. I think it is worth
>>> investigating for Continuum 2.0 - WDYT?
>>
>> I need a reason to drop the current set of technologies, why is the
>> new set better etc.
> My motivations behind this were:
> # leverage Java 5 language and other library features, and enable
> Continuum to do the same.
> # Encourage more contributions by using tools/libraries that have a
> good user base.
>
> <snipped>
>>> 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.
>>
>> This is way to detailed to be on a roadmap.
> Yep, way too detailed for the roadmap but that was just a random
> thought, please ignore it at this stage ;-)
>
> <snipped>
>>> 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 not sure what you're trying to say here. The current way to
>> installing Continuum (unpack, run bin/plexus.sh) is still giving me
>> "wow" when doing demos.
> I was just hinting if Continuum dist could be leaner, but again may be
> too early at this point in time
Leaner in what way?
>>
>> What I would like to see is talk about the different ways of doing
>> remoting and tool integration (IDEs in particular, but also desktop
>> widgets).
> +1
>>
>> Overall I think the core of Continuum should be re-though to be more
>> pluggable. In particular a workflow engine should be in the middle of
>> the execution to orchestrate any steps involved with building a
>> project. This is one of the places where people should be able to plug
>> in their own steps and functionality.
> +1
>>
>> If someone is going down the plugin path, it is essential to me that
>> these plugins can be written in vi inside an existing installation and
>> copied around. This implies to me that we have to support a plugin
>> language like jython, jruby or groovy.
> I agree with the possibility supporting multiple plugin languages in the
> long run but just having support for Java based plugins for starters. I
> am not yet sure what all is involved in supporting plugins in other
> languages.
I didn't mean to say that Continuum should support *multiple* languages,
only that it should support *a* language. My point was that when people
are to customize their server they shouldn't have to start an IDE to
create plugin. It should be possible to just mock around with some
plugin files on the command line.
--
Trygve
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
<snipped>
>> 1-2) I would like to bring Guice to the mix. I think it is worth
>> investigating for Continuum 2.0 - WDYT?
>
> I need a reason to drop the current set of technologies, why is the
> new set better etc.
My motivations behind this were:
# leverage Java 5 language and other library features, and enable
Continuum to do the same.
# Encourage more contributions by using tools/libraries that have a
good user base.
<snipped>
>> 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.
>
> This is way to detailed to be on a roadmap.
Yep, way too detailed for the roadmap but that was just a random
thought, please ignore it at this stage ;-)
<snipped>
>> 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 not sure what you're trying to say here. The current way to
> installing Continuum (unpack, run bin/plexus.sh) is still giving me
> "wow" when doing demos.
I was just hinting if Continuum dist could be leaner, but again may be
too early at this point in time
>
> What I would like to see is talk about the different ways of doing
> remoting and tool integration (IDEs in particular, but also desktop
> widgets).
+1
>
> Overall I think the core of Continuum should be re-though to be more
> pluggable. In particular a workflow engine should be in the middle of
> the execution to orchestrate any steps involved with building a
> project. This is one of the places where people should be able to plug
> in their own steps and functionality.
+1
>
> If someone is going down the plugin path, it is essential to me that
> these plugins can be written in vi inside an existing installation and
> copied around. This implies to me that we have to support a plugin
> language like jython, jruby or groovy.
I agree with the possibility supporting multiple plugin languages in the
long run but just having support for Java based plugins for starters. I
am not yet sure what all is involved in supporting plugins in other
languages.
Rahul
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Trygve Laugstøl <tr...@apache.org>.
Rahul Thakur wrote:
>
>> Overall I think the core of Continuum should be re-though to be more
>> pluggable. In particular a workflow engine should be in the middle of
>> the execution to orchestrate any steps involved with building a
>> project. This is one of the places where people should be able to plug
>> in their own steps and functionality.
> Is this close to what you are thinking?
> http://www.eclipse.org/alf/index.php
After a 30 second look, I don't think so. More like this:
http://www.jboss.com/products/jbpm
--
Trygve
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
> Overall I think the core of Continuum should be re-though to be more
> pluggable. In particular a workflow engine should be in the middle of
> the execution to orchestrate any steps involved with building a
> project. This is one of the places where people should be able to plug
> in their own steps and functionality.
Is this close to what you are thinking?
http://www.eclipse.org/alf/index.php
Rahul
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Trygve Laugstøl <tr...@apache.org>.
Rahul Thakur 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.
Annotations is nice, but really isn't what is stopping Continuum from
moving ahead. Moving to standardized, mature technologies will probably
be smart in the long run as it is easier to get help and for other to
contribute.
> 1-2) I would like to bring Guice to the mix. I think it is worth
> investigating for Continuum 2.0 - WDYT?
I need a reason to drop the current set of technologies, why is the new
set better etc.
> 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.
JPA annotations is probably a good idea as you'll get IDE support etc
from the start.
> 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.
This is way to detailed to be on a roadmap.
> 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.
This is something that definitely should be at the core of the 2.0
architecture.
> 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?
Same as the previous point, +1.
> 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.
GWT vs anything else again way to specific when you're talking roadmap.
Doing experiments is a good thing, I'm not trying to shoot anything down
here, but focus needs to stay on *features* and then we can try to find
a suiting set of *technologies* when/if it comes down to that.
> 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.
Reporting is something that definitely can be improved.
> 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.
More documentation is always useful, yes.
> 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 not sure what you're trying to say here. The current way to
installing Continuum (unpack, run bin/plexus.sh) is still giving me
"wow" when doing demos.
What I would like to see is talk about the different ways of doing
remoting and tool integration (IDEs in particular, but also desktop
widgets).
Overall I think the core of Continuum should be re-though to be more
pluggable. In particular a workflow engine should be in the middle of
the execution to orchestrate any steps involved with building a project.
This is one of the places where people should be able to plug in their
own steps and functionality.
If someone is going down the plugin path, it is essential to me that
these plugins can be written in vi inside an existing installation and
copied around. This implies to me that we have to support a plugin
language like jython, jruby or groovy.
--
Trygve
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Emmanuel Venisse <em...@gmail.com>.
On Jan 30, 2008 9:54 PM, Wendy Smoak <ws...@gmail.com> wrote:
> On Jan 30, 2008 12:34 PM, Jesse McConnell <je...@gmail.com>
> 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
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Wendy Smoak <ws...@gmail.com>.
On Jan 30, 2008 12:34 PM, Jesse McConnell <je...@gmail.com> 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
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Gordon Yorke <go...@kandgyorke.ca>.
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 <go...@kandgyorke.ca>
> 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@gmail.com
>
>
--
View this message in context: http://www.nabble.com/-Discussion--Continuum-2.0-Roadmap-tp15171171p15191100.html
Sent from the Continuum - Dev mailing list archive at Nabble.com.
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Jesse McConnell <je...@gmail.com>.
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 <go...@kandgyorke.ca> 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@gmail.com
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Gordon Yorke <go...@kandgyorke.ca>.
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.
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
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
>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Tomasz Pik <to...@gmail.com>.
On Feb 6, 2008 6:52 AM, Christian Edward Gruber <cg...@israfil.net> wrote:
> LOL. I'm so out of date. I used to work with TopLink way back in the
> earliest days, and tracked it up to the Oracle buyout. After that I
> didn't pay attention, and it's clearly changed direction. Never knew
> the core was open-sourced.
>
> Anyway, it's always been one of the better OR/M platforms, so I'd be
> cool with it if the license is Apache-compatible.
BTW Hibernate is LGPL so as far as I know it's not Apache-compatible.
Regards,
Tomek
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Christian Edward Gruber <cg...@israfil.net>.
LOL. I'm so out of date. I used to work with TopLink way back in the
earliest days, and tracked it up to the Oracle buyout. After that I
didn't pay attention, and it's clearly changed direction. Never knew
the core was open-sourced.
Anyway, it's always been one of the better OR/M platforms, so I'd be
cool with it if the license is Apache-compatible.
Christian.
On 6-Feb-08, at 00:03 , Rahul Thakur wrote:
> TopLink Essentials
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Christian Edward Gruber <cg...@israfil.net>.
Incidentally, according to this:
http://people.apache.org/~cliffs/3party.html
CDDL software can be included in binary form (so as a binary maven
dependency), but the project would not be able to ship any source from
it.
regards,
Christian.
On 6-Feb-08, at 00:03 , Rahul Thakur wrote:
> 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
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
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 <em...@venisse.net> 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
>>
>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Christian Edward Gruber <cg...@israfil.net>.
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 <em...@venisse.net>
>> 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
>>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Jesse McConnell <je...@gmail.com>.
ya I would agree with erik on this one...its a great idea that it would work
that way but in reality...its hard enough to switch out databases much less
the layer between your goop and the databases
jesse
On Feb 6, 2008 1:51 PM, Erik Bengtson <er...@jpox.org> wrote:
> FYI, JPA TCK has very low coverage over the spec itself, that said being
> compliant is certainly not a portability label.
>
> You will only get portability if you test your jpa code against all
> implementations and find the lowest common denominator.
>
> -----Message d'origine-----
> De : Thierry Lach [mailto:thierry.lach@gmail.com]
> Envoyé : mercredi 6 février 2008 17:34
> À : continuum-dev@maven.apache.org
> Objet : Re: [Discussion] Continuum 2.0 Roadmap
>
> Hibernate can be used in a completely JPA-compliant mode, so it would be
> (theoretically) just as swappable as any other JPA implementation as long
> as
> you don't use any hibernate-specific extensions.
>
> On Feb 5, 2008 10:12 PM, Christian Edward Gruber <cg...@israfil.net>
> 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 <em...@venisse.net>
> > > 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
> > >
> >
> >
>
>
--
jesse mcconnell
jesse.mcconnell@gmail.com
RE: [Discussion] Continuum 2.0 Roadmap
Posted by Erik Bengtson <er...@jpox.org>.
FYI, JPA TCK has very low coverage over the spec itself, that said being
compliant is certainly not a portability label.
You will only get portability if you test your jpa code against all
implementations and find the lowest common denominator.
-----Message d'origine-----
De : Thierry Lach [mailto:thierry.lach@gmail.com]
Envoyé : mercredi 6 février 2008 17:34
À : continuum-dev@maven.apache.org
Objet : Re: [Discussion] Continuum 2.0 Roadmap
Hibernate can be used in a completely JPA-compliant mode, so it would be
(theoretically) just as swappable as any other JPA implementation as long as
you don't use any hibernate-specific extensions.
On Feb 5, 2008 10:12 PM, Christian Edward Gruber <cg...@israfil.net>
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 <em...@venisse.net>
> > 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
> >
>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Christian Edward Gruber <cg...@israfil.net>.
Sorry, that was sort of my point - many implementation-specific tricks
make it into OR/M configuration, and sometimes code. Or rather
assumptions about subtle behaviour or one ORM are factored into the
design, but another ORM may not perform in the same way under the same
conditions because it's internally optimized differently.
Also, unfortunately, a lot of this configuration ends up in
Annotations in JPA, so the code is not really portable POJOs. So
while it can be largely swappable, let's just not get fooled into
thinking it's "easily swappable without effort" and then do no due-
diligence around what the default JPA implementation would be.
Having said that, JPA itself is based on a much stronger approach to
ORM than many previous ones, and if Toplink provides reference
implementation code then I'd be inclined to trust it. It's one of the
most battle-tested ORM's out there. Of course hibernate has much more
currency in the open-source community.
Christian.
On 6-Feb-08, at 11:33 , Thierry Lach wrote:
> Hibernate can be used in a completely JPA-compliant mode, so it
> would be
> (theoretically) just as swappable as any other JPA implementation as
> long as
> you don't use any hibernate-specific extensions.
>
> On Feb 5, 2008 10:12 PM, Christian Edward Gruber <cg...@israfil.net>
> 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 <em...@venisse.net>
>>> 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
>>>
>>
>>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Thierry Lach <th...@gmail.com>.
Hibernate can be used in a completely JPA-compliant mode, so it would be
(theoretically) just as swappable as any other JPA implementation as long as
you don't use any hibernate-specific extensions.
On Feb 5, 2008 10:12 PM, Christian Edward Gruber <cg...@israfil.net>
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 <em...@venisse.net>
> > 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
> >
>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Christian Edward Gruber <cg...@israfil.net>.
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 <em...@venisse.net>
> 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
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Carlos Sanchez <ca...@apache.org>.
well, if you want to have a plugin based architecture, what better
that OSGi? and it may help too for distributiion of build machines
On Feb 6, 2008 2:08 AM, Rahul Thakur <ra...@gmail.com> wrote:
> Are you thinking what I am thinking - an OSGi based runtime underneath
> and plugins/extensions that could be loaded runtime?
> :-)
>
>
> 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 <em...@venisse.net> 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
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
Are you thinking what I am thinking - an OSGi based runtime underneath
and plugins/extensions that could be loaded runtime?
:-)
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 <em...@venisse.net> 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
>>
>>
>
>
>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Brett Porter <br...@apache.org>.
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
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Christian Edward Gruber <cg...@israfil.net>.
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<ca...@apache.org> 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<em...@venisse.net>
>>> 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
>>>
>>>
>>
>>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
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<ca...@apache.org> 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<em...@venisse.net> 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
>>
>>
>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by "Napoleon Esmundo C. Ramirez" <na...@gmail.com>.
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 <ca...@apache.org> 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 <em...@venisse.net> 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
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Carlos Sanchez <ca...@apache.org>.
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 <em...@venisse.net> 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
Re: wiki was: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
I have created an page for Continuum 2.0 related stuff (treat this as a
dashboard with links to related C2 docs).
http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Draft+-+Continuum+2.0
The other content will keep moving in the background.
Cheers,
Rahul
Emmanuel Venisse wrote:
> Thanks Brett.
>
> I'm +1 to open it.
>
> Emmanuel
>
> On Feb 13, 2008 8:43 AM, Brett Porter <br...@apache.org> wrote:
>
>
>> no, permissions changes are non-destructive :)
>>
>> On 13/02/2008, at 6:33 PM, Rahul Thakur wrote:
>>
>>
>>> +1 as long as editing it requires a login :-)
>>>
>>> Should I hold off the migration from Codehaus?
>>>
>>> Rahul
>>>
>>> On Feb 13, 2008 6:32 PM, Brett Porter <br...@apache.org> wrote:
>>>
>>>> On 13/02/2008, at 4:04 PM, Wendy Smoak wrote:
>>>>
>>>>
>>>>> On Feb 12, 2008 10:01 PM, Brett Porter <br...@apache.org> wrote:
>>>>>
>>>>>> Ok, I've created two wiki's:
>>>>>>
>>>>> ...
>>>>>
>>>>>> http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Index
>>>>>> (exported to: http://cwiki.apache.org/CONTINUUMDEV/)
>>>>>>
>>>>>> This one is editable by developers only (accepts comments from
>>>>>> anyone). This is for the roadmap and design docs. I only granted
>>>>>> access to a few people that I could easily find - if you need to
>>>>>> edit,
>>>>>> just let me or a confluence admin know.
>>>>>>
>>>>> Why would we not want to allow the community to participate in
>>>>> roadmap
>>>>> and design docs?
>>>>>
>>>>> The only reason I can think of to restrict access is to make sure we
>>>>> have a CLA for content we intend to redistribute.
>>>>>
>>>> Both good points - I was following what we had in Maven already -
>>>> what
>>>> do others think - shall we just open it up? Or do we not even need
>>>> the
>>>> DEV space?
>>>>
>>>> - Brett
>>>>
>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>>
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>>
>
>
Re: wiki was: [Discussion] Continuum 2.0 Roadmap
Posted by Emmanuel Venisse <em...@gmail.com>.
Thanks Brett.
I'm +1 to open it.
Emmanuel
On Feb 13, 2008 8:43 AM, Brett Porter <br...@apache.org> wrote:
> no, permissions changes are non-destructive :)
>
> On 13/02/2008, at 6:33 PM, Rahul Thakur wrote:
>
> > +1 as long as editing it requires a login :-)
> >
> > Should I hold off the migration from Codehaus?
> >
> > Rahul
> >
> > On Feb 13, 2008 6:32 PM, Brett Porter <br...@apache.org> wrote:
> >>
> >>
> >> On 13/02/2008, at 4:04 PM, Wendy Smoak wrote:
> >>
> >>> On Feb 12, 2008 10:01 PM, Brett Porter <br...@apache.org> wrote:
> >>>> Ok, I've created two wiki's:
> >>> ...
> >>>> http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Index
> >>>> (exported to: http://cwiki.apache.org/CONTINUUMDEV/)
> >>>>
> >>>> This one is editable by developers only (accepts comments from
> >>>> anyone). This is for the roadmap and design docs. I only granted
> >>>> access to a few people that I could easily find - if you need to
> >>>> edit,
> >>>> just let me or a confluence admin know.
> >>>
> >>> Why would we not want to allow the community to participate in
> >>> roadmap
> >>> and design docs?
> >>>
> >>> The only reason I can think of to restrict access is to make sure we
> >>> have a CLA for content we intend to redistribute.
> >>
> >> Both good points - I was following what we had in Maven already -
> >> what
> >> do others think - shall we just open it up? Or do we not even need
> >> the
> >> DEV space?
> >>
> >> - Brett
> >>
> >> --
> >> Brett Porter
> >> brett@apache.org
> >>
> >> http://blogs.exist.com/bporter/
> >>
> >>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: wiki was: [Discussion] Continuum 2.0 Roadmap
Posted by Brett Porter <br...@apache.org>.
no, permissions changes are non-destructive :)
On 13/02/2008, at 6:33 PM, Rahul Thakur wrote:
> +1 as long as editing it requires a login :-)
>
> Should I hold off the migration from Codehaus?
>
> Rahul
>
> On Feb 13, 2008 6:32 PM, Brett Porter <br...@apache.org> wrote:
>>
>>
>> On 13/02/2008, at 4:04 PM, Wendy Smoak wrote:
>>
>>> On Feb 12, 2008 10:01 PM, Brett Porter <br...@apache.org> wrote:
>>>> Ok, I've created two wiki's:
>>> ...
>>>> http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Index
>>>> (exported to: http://cwiki.apache.org/CONTINUUMDEV/)
>>>>
>>>> This one is editable by developers only (accepts comments from
>>>> anyone). This is for the roadmap and design docs. I only granted
>>>> access to a few people that I could easily find - if you need to
>>>> edit,
>>>> just let me or a confluence admin know.
>>>
>>> Why would we not want to allow the community to participate in
>>> roadmap
>>> and design docs?
>>>
>>> The only reason I can think of to restrict access is to make sure we
>>> have a CLA for content we intend to redistribute.
>>
>> Both good points - I was following what we had in Maven already -
>> what
>> do others think - shall we just open it up? Or do we not even need
>> the
>> DEV space?
>>
>> - Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>>
>> http://blogs.exist.com/bporter/
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: wiki was: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
+1 as long as editing it requires a login :-)
Should I hold off the migration from Codehaus?
Rahul
On Feb 13, 2008 6:32 PM, Brett Porter <br...@apache.org> wrote:
>
>
> On 13/02/2008, at 4:04 PM, Wendy Smoak wrote:
>
> > On Feb 12, 2008 10:01 PM, Brett Porter <br...@apache.org> wrote:
> >> Ok, I've created two wiki's:
> > ...
> >> http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Index
> >> (exported to: http://cwiki.apache.org/CONTINUUMDEV/)
> >>
> >> This one is editable by developers only (accepts comments from
> >> anyone). This is for the roadmap and design docs. I only granted
> >> access to a few people that I could easily find - if you need to
> >> edit,
> >> just let me or a confluence admin know.
> >
> > Why would we not want to allow the community to participate in roadmap
> > and design docs?
> >
> > The only reason I can think of to restrict access is to make sure we
> > have a CLA for content we intend to redistribute.
>
> Both good points - I was following what we had in Maven already - what
> do others think - shall we just open it up? Or do we not even need the
> DEV space?
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
>
> http://blogs.exist.com/bporter/
>
>
Re: wiki was: [Discussion] Continuum 2.0 Roadmap
Posted by Brett Porter <br...@apache.org>.
On 13/02/2008, at 4:04 PM, Wendy Smoak wrote:
> On Feb 12, 2008 10:01 PM, Brett Porter <br...@apache.org> wrote:
>> Ok, I've created two wiki's:
> ...
>> http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Index
>> (exported to: http://cwiki.apache.org/CONTINUUMDEV/)
>>
>> This one is editable by developers only (accepts comments from
>> anyone). This is for the roadmap and design docs. I only granted
>> access to a few people that I could easily find - if you need to
>> edit,
>> just let me or a confluence admin know.
>
> Why would we not want to allow the community to participate in roadmap
> and design docs?
>
> The only reason I can think of to restrict access is to make sure we
> have a CLA for content we intend to redistribute.
Both good points - I was following what we had in Maven already - what
do others think - shall we just open it up? Or do we not even need the
DEV space?
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: wiki was: [Discussion] Continuum 2.0 Roadmap
Posted by Wendy Smoak <ws...@gmail.com>.
On Feb 12, 2008 10:01 PM, Brett Porter <br...@apache.org> wrote:
> Ok, I've created two wiki's:
...
> http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Index
> (exported to: http://cwiki.apache.org/CONTINUUMDEV/)
>
> This one is editable by developers only (accepts comments from
> anyone). This is for the roadmap and design docs. I only granted
> access to a few people that I could easily find - if you need to edit,
> just let me or a confluence admin know.
Why would we not want to allow the community to participate in roadmap
and design docs?
The only reason I can think of to restrict access is to make sure we
have a CLA for content we intend to redistribute.
--
Wendy
Re: wiki was: [Discussion] Continuum 2.0 Roadmap
Posted by Brett Porter <br...@apache.org>.
Ok, I've created two wiki's:
http://cwiki.apache.org/confluence/display/CONTINUUM/Index
(exported to: http://cwiki.apache.org/CONTINUUM/)
This one is open to all users to edit, so is the traditional wiki/
cookbook area.
http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Index
(exported to: http://cwiki.apache.org/CONTINUUMDEV/)
This one is editable by developers only (accepts comments from
anyone). This is for the roadmap and design docs. I only granted
access to a few people that I could easily find - if you need to edit,
just let me or a confluence admin know.
So once this is migrated, we can point the Codehaus ones at this.
I have not yet set up an rsync to people.apache.org - if there's a
place we should house this under the Continuum site we can do that.
Also, the template probably needs some modifications.
Cheers,
Brett
On 07/02/2008, at 6:04 AM, Rahul Thakur wrote:
>
> If everyone is happy to keep the history till date on codehaus wiki,
> I can help copy stuff across to Apache wiki :-)
>
> Rahul
>
>
> Brett Porter wrote:
>> We can create such a wiki any time - the challenge is converting
>> existing content. If someone is happy to lose history and do it by
>> hand, it can be done straight away.
>>
>> On 06/02/2008, at 9:25 PM, Rahul Thakur wrote:
>>
>>> Some good points emerging from this discussion! :-)
>>>
>>> Would it be a nice idea to put following on wiki:
>>> 1) State goals/philosophy for C2 in light of lessons learnt from
>>> 1.x development - lean, mean, extensible (~add any other here~)
>>> 2) Document *all* features/requirements we want to see in C2 on
>>> wiki (even if they are already present in 1.x!).
>>> 3) Draw a proposed architecture.
>>> 4) Assign items in (1) a priority/weight. Add use-cases to each
>>> item in (1) to determine this.
>>> 5) Group the priortised requirements/features into milestones.
>>> 6) Start cutting code.
>>>
>>> Thoughts?
>>>
>>> PS: Codehaus wiki seems to be very slow. Any chance we can have a
>>> space created on Apache wiki? Or, I guess it will have to wait for
>>> TLP vote.
>>>
>>> Cheers,
>>> Rahul
>>>
>>> Brett Porter wrote:
>>>> 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
>>>>
>>>>
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
If everyone is happy to keep the history till date on codehaus wiki, I
can help copy stuff across to Apache wiki :-)
Rahul
Brett Porter wrote:
> We can create such a wiki any time - the challenge is converting
> existing content. If someone is happy to lose history and do it by
> hand, it can be done straight away.
>
> On 06/02/2008, at 9:25 PM, Rahul Thakur wrote:
>
>> Some good points emerging from this discussion! :-)
>>
>> Would it be a nice idea to put following on wiki:
>> 1) State goals/philosophy for C2 in light of lessons learnt from 1.x
>> development - lean, mean, extensible (~add any other here~)
>> 2) Document *all* features/requirements we want to see in C2 on wiki
>> (even if they are already present in 1.x!).
>> 3) Draw a proposed architecture.
>> 4) Assign items in (1) a priority/weight. Add use-cases to each item
>> in (1) to determine this.
>> 5) Group the priortised requirements/features into milestones.
>> 6) Start cutting code.
>>
>> Thoughts?
>>
>> PS: Codehaus wiki seems to be very slow. Any chance we can have a
>> space created on Apache wiki? Or, I guess it will have to wait for
>> TLP vote.
>>
>> Cheers,
>> Rahul
>>
>> Brett Porter wrote:
>>> 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
>>>
>>>
>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Brett Porter <br...@apache.org>.
We can create such a wiki any time - the challenge is converting
existing content. If someone is happy to lose history and do it by
hand, it can be done straight away.
On 06/02/2008, at 9:25 PM, Rahul Thakur wrote:
> Some good points emerging from this discussion! :-)
>
> Would it be a nice idea to put following on wiki:
> 1) State goals/philosophy for C2 in light of lessons learnt from
> 1.x development - lean, mean, extensible (~add any other here~)
> 2) Document *all* features/requirements we want to see in C2 on
> wiki (even if they are already present in 1.x!).
> 3) Draw a proposed architecture.
> 4) Assign items in (1) a priority/weight. Add use-cases to each
> item in (1) to determine this.
> 5) Group the priortised requirements/features into milestones.
> 6) Start cutting code.
>
> Thoughts?
>
> PS: Codehaus wiki seems to be very slow. Any chance we can have a
> space created on Apache wiki? Or, I guess it will have to wait for
> TLP vote.
>
> Cheers,
> Rahul
>
> Brett Porter wrote:
>> 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
>>
>>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
Some good points emerging from this discussion! :-)
Would it be a nice idea to put following on wiki:
1) State goals/philosophy for C2 in light of lessons learnt from 1.x
development - lean, mean, extensible (~add any other here~)
2) Document *all* features/requirements we want to see in C2 on wiki
(even if they are already present in 1.x!).
3) Draw a proposed architecture.
4) Assign items in (1) a priority/weight. Add use-cases to each item in
(1) to determine this.
5) Group the priortised requirements/features into milestones.
6) Start cutting code.
Thoughts?
PS: Codehaus wiki seems to be very slow. Any chance we can have a space
created on Apache wiki? Or, I guess it will have to wait for TLP vote.
Cheers,
Rahul
Brett Porter wrote:
> 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
>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Brett Porter <br...@apache.org>.
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
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Emmanuel Venisse <em...@gmail.com>.
Thanks Rahul.
Emmanuel
On Feb 20, 2008 4:44 AM, Rahul Thakur <ra...@gmail.com> wrote:
> Hi,
>
> I have re-organised and updated content related to Continuum 2.0 Roadmap
> here:
>
> http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Draft+-+Continuum+2.0+Roadmap
>
> Would appreciate if others can review/update/comment as appropriate.
>
> Also, I think we start cutting out concrete JIRA tasks from those
> umbrella issues listed on that page above and assign them fix versions.
>
> 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
> >
> >
>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
Hi,
I have re-organised and updated content related to Continuum 2.0 Roadmap
here:
http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Draft+-+Continuum+2.0+Roadmap
Would appreciate if others can review/update/comment as appropriate.
Also, I think we start cutting out concrete JIRA tasks from those
umbrella issues listed on that page above and assign them fix versions.
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
>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Olivier Lamy <ol...@apache.org>.
Hi,
This looks very exciting (I love the plugin idea).
As all of this features can be long to implement, I agree with Brett
to separate into different millestones releases. (IMHO a full "big
bang" will be very long).
And currently they are some blocking issues in the 1.1 release.
--
Olivier
2008/1/29, Emmanuel Venisse <em...@venisse.net>:
> 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
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Erik Drolshammer <er...@fjas.no>.
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
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Maria Odea Ching <oc...@apache.org>.
Sorry, just caught up with my mails today..
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.
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.
Thanks,
Deng
On Jan 30, 2008 6:34 AM, Emmanuel Venisse <em...@venisse.net> 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
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Edwin Punzalan <ep...@apache.org>.
I can only agree on the pointers given in the wiki. However, I'd like to
reiterate the low significance of database portability in a CI server. I
think speed matters but not really portability.
Andy seems to be willing to help solve the database problems Continuum is
experiencing.
Just my 2 cents, though. ^_^
On Jan 29, 2008 2:34 PM, Emmanuel Venisse <em...@venisse.net> 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
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Brett Porter <br...@apache.org>.
On 21/02/2008, at 9:57 AM, Rahul Thakur wrote:
>
> Another feature (rather features) that i would like to see is around
> Change tracking/audit.
>
> I would like to add to the feature list - integration with some of
> popular Change management/ Bug tracking systems, such that user can
> see issues fixed in a build.
I think just keep adding them and make this a collection page rather
than a 2.0 page. Then they can gather volunteers, more info. Then
split out the really focused ones that you're planning to work on
right now.
>
>
> On a related note, I think we are already capturing changes in the
> SCM but we should present them in the separate view for more
> visibility.
+1
>
>
> WDYT?
>
> Cheers,
> 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
>>
>>
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Emmanuel Venisse <em...@gmail.com>.
+1, maybe as a UI plugin
Emmanuel
On Wed, Feb 20, 2008 at 11:57 PM, Rahul Thakur <ra...@gmail.com>
wrote:
>
> Another feature (rather features) that i would like to see is around
> Change tracking/audit.
>
> I would like to add to the feature list - integration with some of
> popular Change management/ Bug tracking systems, such that user can see
> issues fixed in a build.
>
> On a related note, I think we are already capturing changes in the SCM
> but we should present them in the separate view for more visibility.
>
> WDYT?
>
> Cheers,
> 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
> >
> >
>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
Another feature (rather features) that i would like to see is around
Change tracking/audit.
I would like to add to the feature list - integration with some of
popular Change management/ Bug tracking systems, such that user can see
issues fixed in a build.
On a related note, I think we are already capturing changes in the SCM
but we should present them in the separate view for more visibility.
WDYT?
Cheers,
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
>
>
Re: [Discussion] Continuum 2.0 Roadmap
Posted by Rahul Thakur <ra...@gmail.com>.
Hello Everyone,
I have re-organized the document on the cwiki.apache.org
http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Continuum+2.0+Roadmap*
*and, moved the items into their own child pages. I think we should have
a template to lend some structure to requirements captured and expand them.
Any suggestions?
Cheers,
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
>
>