Re: [Discussion] Continuum 2.0 Roadmap
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
