Re: [Discussion] Continuum 2.0 Roadmap

2008-02-20 Thread Emmanuel Venisse
Thanks Rahul.

Emmanuel

On Feb 20, 2008 4:44 AM, Rahul Thakur [EMAIL PROTECTED] 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

2008-02-20 Thread Rahul Thakur


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

2008-02-20 Thread Brett Porter


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
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/



Re: [Discussion] Continuum 2.0 Roadmap

2008-02-19 Thread Rahul Thakur

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

2008-02-17 Thread Maria Odea Ching
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 [EMAIL PROTECTED] wrote:

 Hi

 I started a document [1] with my ideas about Continuum 2.
 As you can see in this doc, I want to add lot of things in the next
 version.

 Feel free to comment on it.


 [1]
 http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion

 Emmanuel



Re: [Discussion] Continuum 2.0 Roadmap

2008-02-17 Thread Erik Drolshammer

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

2008-02-17 Thread Rahul Thakur


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

   




Re: [Discussion] Continuum 2.0 Roadmap

2008-02-08 Thread Rahul Thakur


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

2008-02-07 Thread Rahul Thakur


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

2008-02-07 Thread Rahul Thakur


Here's my list:

1)  Peformance improvements.
2)  A slicker User Interface. Ability to let the user work in an offline 
mode (Google Gears!) and sync periodically.

3)  Good user and developer documentation.
4)  Better public APIs (rework Store and Continuum)

Rahul

Napoleon Esmundo C. Ramirez wrote:

Just some thoughts,

I strongly agree to the proposed technology changes, particularly in the
database, as it will definitely improve the storage performance.  In line
with the objectives to make Continuum a slick CI server, I think the design
changes is a good move as well.  In my opinion, having plugins will provide
a platform for flexibility and a workflow-type of approach in managing the
builds.

My proposed features would be the following:
1.  Aside from the improvement in the UI, I think a visual representation of
statistics would be nice.  Graphs of the success rates, charts of project
health, etc.  I think Bamboo has it as telemetry.
2.  Distributed builds, this has been started before but it was never used.
I think this would be a strong point in using Continuum if it were
available.  Hudson has it, iirc.  I think implementing it as a plugin would
provide more control to it.

Again, just my thoughts.

Cheers!
Nap

On Feb 6, 2008 8:12 AM, Carlos Sanchez[EMAIL PROTECTED]  wrote:

   

Some comments

Database vs xml: definitely database. Throwing away the db access api
(JDO/JPA/...) now that it's already there doesnt make much sense.
Maybe there are implementations that use xml for storage and that's
where you'd need to look if you want file storage

Spring vs Guice vs Plexus: Spring for sure. Big community, lots of
users, documentation, support,... Specially if you want to add JMX
support (can be done really easily just with annotations using
reflection), and thinking in OSGi in the future I'm sure it will be
really easy to integrate Spring and OSGi if it is not already. I'd
start softly, just migrating thing that would require adding features
to plexus, and move from there.

I agree with Brett on having 1.2, 1.3,... it's good to have a list of
what you want to do for 2.0 but as it gets done it should be released
in minor versions.

On Jan 29, 2008 2:34 PM, Emmanuel Venisse[EMAIL PROTECTED]  wrote:
 

Hi

I started a document [1] with my ideas about Continuum 2.
As you can see in this doc, I want to add lot of things in the next
   

version.
 

Feel free to comment on it.


[1]

   

http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion
 

Emmanuel

   


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

 


   




Re: [Discussion] Continuum 2.0 Roadmap

2008-02-07 Thread Christian Edward Gruber
1.  +1 on distributed builds, along with examples on the 2 main use  
cases I see for distributed builds:
 a. building on many platforms for native builds that need  
multiple distributions.
 b. distribute the build across many machines to decrease the  
latency of building everything.


2. +1 on the docs comment below.

3. As to slicker UI, I'm not sure it's as necessary, and there's  
nothing stopping 1.x from getting a better UI.  The bigger issues for  
me are:

a) better co-ordination of reports/dashboards
	b) integrations with various other systems and dashboards and  
monitors (mylyn, jira, etc.)


4. Full configuration of the bootstrapping/staging of the build  
environment.  I'm still experimenting with the current mechanisms, but  
I think it still needs work.


5. Apart from distributed builds, I think we need parallel building of  
mutually independent projects.


I care less about the underlying technologies because most people  
won't be adding osgi or plexus or picocontainer components willy- 
nilly.  I would replace plexus if it is deficient, but unless there's  
a compelling reason to switch, I wouldn't work at it too hard.  For  
example, if it was based on Tapestry (not a plug, just an example),  
then moving to tapestry-ioc would make sense because t5 comes with it,  
it's based on that model, and it cleanly integrates with spring for  
extension.  In that case, however, it's a change for convenience.  I'd  
be even happier if such a switch of any given subsystem was because of  
a solid decision of either defect in the current approach, or  
improvement in the new one.  Spring makes me a bit woodgy because  
while it's an IoC container, it's not really (in my experience) a  
great plug-in system.  An infrastructure around a plugin lifecycle  
would need to be built on or (3rd party) added to spring to make it  
really useable that way.


Christian.

On 7-Feb-08, at 21:56 , Rahul Thakur wrote:



Here's my list:

1)  Peformance improvements.
2)  A slicker User Interface. Ability to let the user work in an  
offline mode (Google Gears!) and sync periodically.

3)  Good user and developer documentation.
4)  Better public APIs (rework Store and Continuum)

Rahul

Napoleon Esmundo C. Ramirez wrote:

Just some thoughts,

I strongly agree to the proposed technology changes, particularly  
in the
database, as it will definitely improve the storage performance.   
In line
with the objectives to make Continuum a slick CI server, I think  
the design
changes is a good move as well.  In my opinion, having plugins will  
provide
a platform for flexibility and a workflow-type of approach in  
managing the

builds.

My proposed features would be the following:
1.  Aside from the improvement in the UI, I think a visual  
representation of
statistics would be nice.  Graphs of the success rates, charts of  
project

health, etc.  I think Bamboo has it as telemetry.
2.  Distributed builds, this has been started before but it was  
never used.

I think this would be a strong point in using Continuum if it were
available.  Hudson has it, iirc.  I think implementing it as a  
plugin would

provide more control to it.

Again, just my thoughts.

Cheers!
Nap

On Feb 6, 2008 8:12 AM, Carlos Sanchez[EMAIL PROTECTED]  wrote:



Some comments

Database vs xml: definitely database. Throwing away the db access  
api

(JDO/JPA/...) now that it's already there doesnt make much sense.
Maybe there are implementations that use xml for storage and that's
where you'd need to look if you want file storage

Spring vs Guice vs Plexus: Spring for sure. Big community, lots of
users, documentation, support,... Specially if you want to add JMX
support (can be done really easily just with annotations using
reflection), and thinking in OSGi in the future I'm sure it will be
really easy to integrate Spring and OSGi if it is not already. I'd
start softly, just migrating thing that would require adding  
features

to plexus, and move from there.

I agree with Brett on having 1.2, 1.3,... it's good to have a list  
of
what you want to do for 2.0 but as it gets done it should be  
released

in minor versions.

On Jan 29, 2008 2:34 PM, Emmanuel Venisse[EMAIL PROTECTED]   
wrote:



Hi

I started a document [1] with my ideas about Continuum 2.
As you can see in this doc, I want to add lot of things in the next


version.


Feel free to comment on it.


[1]



http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion


Emmanuel




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride











Re: [Discussion] Continuum 2.0 Roadmap

2008-02-06 Thread Rahul Thakur

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

2008-02-06 Thread Rahul Thakur
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 [EMAIL PROTECTED] wrote:
  

Hi

I started a document [1] with my ideas about Continuum 2.
As you can see in this doc, I want to add lot of things in the next version.

Feel free to comment on it.


[1]
http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion

Emmanuel






  


Re: [Discussion] Continuum 2.0 Roadmap

2008-02-06 Thread Olivier Lamy
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 [EMAIL PROTECTED]:
 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

2008-02-06 Thread Brett Porter
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

2008-02-06 Thread Carlos Sanchez
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote:
 
  Hi
 
  I started a document [1] with my ideas about Continuum 2.
  As you can see in this doc, I want to add lot of things in the next 
  version.
 
  Feel free to comment on it.
 
 
  [1]
  http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion
 
  Emmanuel
 
 
 
 
 
 




-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride


Re: [Discussion] Continuum 2.0 Roadmap

2008-02-06 Thread Tomasz Pik
On Feb 6, 2008 6:52 AM, Christian Edward Gruber [EMAIL PROTECTED] 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

2008-02-06 Thread Rahul Thakur


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

2008-02-06 Thread Erik Bengtson
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:[EMAIL PROTECTED] 
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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
  wrote:
  Hi
 
  I started a document [1] with my ideas about Continuum 2.
  As you can see in this doc, I want to add lot of things in the next
  version.
 
  Feel free to comment on it.
 
 
  [1]
 
 http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion
 
  Emmanuel
 
 
 
 
  --
  I could give you my word as a Spaniard.
  No good. I've known too many Spaniards.
  -- The Princess Bride
 





Re: [Discussion] Continuum 2.0 Roadmap

2008-02-06 Thread Jesse McConnell
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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]
   wrote:
   Hi
  
   I started a document [1] with my ideas about Continuum 2.
   As you can see in this doc, I want to add lot of things in the next
   version.
  
   Feel free to comment on it.
  
  
   [1]
  
 
 http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion
  
   Emmanuel
  
  
  
  
   --
   I could give you my word as a Spaniard.
   No good. I've known too many Spaniards.
   -- The Princess Bride
  
 
 




-- 
jesse mcconnell
[EMAIL PROTECTED]


Re: [Discussion] Continuum 2.0 Roadmap

2008-02-06 Thread Edwin Punzalan
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 [EMAIL PROTECTED] wrote:

 Hi

 I started a document [1] with my ideas about Continuum 2.
 As you can see in this doc, I want to add lot of things in the next
 version.

 Feel free to comment on it.


 [1]
 http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion

 Emmanuel



Re: [Discussion] Continuum 2.0 Roadmap

2008-02-05 Thread Carlos Sanchez
Some comments

Database vs xml: definitely database. Throwing away the db access api
(JDO/JPA/...) now that it's already there doesnt make much sense.
Maybe there are implementations that use xml for storage and that's
where you'd need to look if you want file storage

Spring vs Guice vs Plexus: Spring for sure. Big community, lots of
users, documentation, support,... Specially if you want to add JMX
support (can be done really easily just with annotations using
reflection), and thinking in OSGi in the future I'm sure it will be
really easy to integrate Spring and OSGi if it is not already. I'd
start softly, just migrating thing that would require adding features
to plexus, and move from there.

I agree with Brett on having 1.2, 1.3,... it's good to have a list of
what you want to do for 2.0 but as it gets done it should be released
in minor versions.

On Jan 29, 2008 2:34 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote:
 Hi

 I started a document [1] with my ideas about Continuum 2.
 As you can see in this doc, I want to add lot of things in the next version.

 Feel free to comment on it.


 [1]
 http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion

 Emmanuel




-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride


Re: [Discussion] Continuum 2.0 Roadmap

2008-02-05 Thread Napoleon Esmundo C. Ramirez
Just some thoughts,

I strongly agree to the proposed technology changes, particularly in the
database, as it will definitely improve the storage performance.  In line
with the objectives to make Continuum a slick CI server, I think the design
changes is a good move as well.  In my opinion, having plugins will provide
a platform for flexibility and a workflow-type of approach in managing the
builds.

My proposed features would be the following:
1.  Aside from the improvement in the UI, I think a visual representation of
statistics would be nice.  Graphs of the success rates, charts of project
health, etc.  I think Bamboo has it as telemetry.
2.  Distributed builds, this has been started before but it was never used.
I think this would be a strong point in using Continuum if it were
available.  Hudson has it, iirc.  I think implementing it as a plugin would
provide more control to it.

Again, just my thoughts.

Cheers!
Nap

On Feb 6, 2008 8:12 AM, Carlos Sanchez [EMAIL PROTECTED] wrote:

 Some comments

 Database vs xml: definitely database. Throwing away the db access api
 (JDO/JPA/...) now that it's already there doesnt make much sense.
 Maybe there are implementations that use xml for storage and that's
 where you'd need to look if you want file storage

 Spring vs Guice vs Plexus: Spring for sure. Big community, lots of
 users, documentation, support,... Specially if you want to add JMX
 support (can be done really easily just with annotations using
 reflection), and thinking in OSGi in the future I'm sure it will be
 really easy to integrate Spring and OSGi if it is not already. I'd
 start softly, just migrating thing that would require adding features
 to plexus, and move from there.

 I agree with Brett on having 1.2, 1.3,... it's good to have a list of
 what you want to do for 2.0 but as it gets done it should be released
 in minor versions.

 On Jan 29, 2008 2:34 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote:
  Hi
 
  I started a document [1] with my ideas about Continuum 2.
  As you can see in this doc, I want to add lot of things in the next
 version.
 
  Feel free to comment on it.
 
 
  [1]
 
 http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion
 
  Emmanuel
 



 --
 I could give you my word as a Spaniard.
 No good. I've known too many Spaniards.
 -- The Princess Bride



Re: [Discussion] Continuum 2.0 Roadmap

2008-02-05 Thread Brett Porter


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

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


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


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


Christian.


On 5-Feb-08, at 19:12 , Carlos Sanchez wrote:


Some comments

Database vs xml: definitely database. Throwing away the db access api
(JDO/JPA/...) now that it's already there doesnt make much sense.
Maybe there are implementations that use xml for storage and that's
where you'd need to look if you want file storage

Spring vs Guice vs Plexus: Spring for sure. Big community, lots of
users, documentation, support,... Specially if you want to add JMX
support (can be done really easily just with annotations using
reflection), and thinking in OSGi in the future I'm sure it will be
really easy to integrate Spring and OSGi if it is not already. I'd
start softly, just migrating thing that would require adding features
to plexus, and move from there.

I agree with Brett on having 1.2, 1.3,... it's good to have a list of
what you want to do for 2.0 but as it gets done it should be released
in minor versions.

On Jan 29, 2008 2:34 PM, Emmanuel Venisse [EMAIL PROTECTED]  
wrote:

Hi

I started a document [1] with my ideas about Continuum 2.
As you can see in this doc, I want to add lot of things in the next  
version.


Feel free to comment on it.


[1]
http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion

Emmanuel





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride





Re: [Discussion] Continuum 2.0 Roadmap

2008-02-05 Thread Rahul Thakur

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 [EMAIL PROTECTED] wrote:

Hi

I started a document [1] with my ideas about Continuum 2.
As you can see in this doc, I want to add lot of things in the next 
version.


Feel free to comment on it.


[1]
http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion 



Emmanuel





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride






Re: [Discussion] Continuum 2.0 Roadmap

2008-02-05 Thread Christian Edward Gruber
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

2008-02-05 Thread Christian Edward Gruber

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

2008-02-02 Thread Rahul Thakur



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

2008-02-01 Thread Rahul Thakur



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

2008-01-31 Thread Emmanuel Venisse
On Jan 30, 2008 9:05 AM, Rahul Thakur [EMAIL PROTECTED] 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 

Re: [Discussion] Continuum 2.0 Roadmap

2008-01-31 Thread Emmanuel Venisse
On Jan 30, 2008 9:54 PM, Wendy Smoak [EMAIL PROTECTED] wrote:

 On Jan 30, 2008 12:34 PM, Jesse McConnell [EMAIL PROTECTED]
 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

2008-01-31 Thread Emmanuel Venisse
On Jan 31, 2008 11:05 PM, Jesse McConnell [EMAIL PROTECTED] 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

2008-01-31 Thread Jesse McConnell

 
  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
[EMAIL PROTECTED]


Re: [Discussion] Continuum 2.0 Roadmap

2008-01-30 Thread Rahul Thakur

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

2008-01-30 Thread Gordon Yorke

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


Rahul Thakur wrote:
 
 
 2) Database
 I am not hard and fast on any particular JPA provider. If Toplink cuts 
 it, we should go with it. I have been toying around with OpenJPA, but I 
 haven't used Toplink to comment on how both compare. OpenJPA is 
 comprehensively documented and has a good support available on mailing 
 lists. Having said that, JPA providers would ultimately be swap'able 
 under the hood.
 
 Also, I think we should stick with JPA annotations on model entities 
 instead of using Modello. I hope writing the data access code from 
 scratch implies the current ContinuumStore will be refactored into 
 something which is less verbose than what we have currently, and so 
 would the Continuum interface.
 
 

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