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
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-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. 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 ;-) 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
Rahul Thakur wrote: Hi, Great to see version 2.0 discussions kicking off! Thanks for putting the ideas on confluence, Emmanuel. :-) Some notes around the ideas outlined on the wiki: 1) Architecture Moving to JSE 5 and JPA is a good idea \o/, it been fairly overdue ;-). 1-1)Can you please elaborate a bit on relationships among - services, various types of facades and entities. A concrete example would help. Annotations is nice, but really isn't what is stopping Continuum from moving ahead. Moving to standardized, mature technologies will probably be smart in the long run as it is easier to get help and for other to contribute. 1-2)I would like to bring Guice to the mix. I think it is worth investigating for Continuum 2.0 - WDYT? I need a reason to drop the current set of technologies, why is the new set better etc. 2) Database I am not hard and fast on any particular JPA provider. If Toplink cuts it, we should go with it. I have been toying around with OpenJPA, but I haven't used Toplink to comment on how both compare. OpenJPA is comprehensively documented and has a good support available on mailing lists. Having said that, JPA providers would ultimately be swap'able under the hood. Also, I think we should stick with JPA annotations on model entities instead of using Modello. I hope writing the data access code from scratch implies the current ContinuumStore will be refactored into something which is less verbose than what we have currently, and so would the Continuum interface. JPA annotations is probably a good idea as you'll get IDE support etc from the start. 3) Builders > Build definitions Just thinking out loud here... Does anyone else see the current Continuum model to be centered around 'Project'? What do you think about 'Build' or BuildDefinition being central? You can add one or more Projects to a Build - we don't need Project Groups, as all we deal with is a Build. Order and dependency can be imposed on a Build composed of more than one project. Notifiers are added to a Build and BuildResult(s) produced for a Build. This is way to detailed to be on a roadmap. 4) Remote Builders I like this idea, but not sure how the build results will be aggregated from remote builders, but may be that is something that needs some more thought. This is something that definitely should be at the core of the 2.0 architecture. 5) Plugins Is this similar to what AntHill Pro has? Are we going to have a notion of Build lifecycle (and phases) to support this? Is this something that can be borrowed in concept (and possibly implementation) from Maven? Same as the previous point, +1. 6) External Access and UI improvements I am +1 for supporting different types of mechanisms to access and control Continuum. Web interface has been the primary interface until now and I totally agree that it needs to be improved to give a better user experience. I welcome the idea of using GWT for this. GWT vs anything else again way to specific when you're talking roadmap. Doing experiments is a good thing, I'm not trying to shoot anything down here, but focus needs to stay on *features* and then we can try to find a suiting set of *technologies* when/if it comes down to that. I am keen to focus more on Reporting as well for this version. As already outlined on the wiki, it would be nice if the reporting can be extended via plugins or some such mechanism. Reporting is something that definitely can be improved. 7) Documentation I would like to add and emphasize here on documenting the code itself as we write it. We are not going to get down to user documentation from day one but there will be users in the community who start consuming the code and contributing back as soon as we starting cooking it! :-) I would like to propose having Checkstyle to flag undocumented source code in codebase. More documentation is always useful, yes. 8) Installation Lastly, I think it would nice to have a core Continuum install to be lean and small with features that can be added by dropping in relevant JARs (and minimal or no configuration). We can actually try different options with development releases before finalizing what should go into the main distro (if at all we break it up) - sounds reasonable? I'm not sure what you're trying to say here. The current way to installing Continuum (unpack, run bin/plexus.sh) is still giving me "wow" when doing demos. What I would like to see is talk about the different ways of doing remoting and tool integration (IDEs in particular, but also desktop widgets). Overall I think the core of Continuum should be re-though to be more pluggable. In particular a workflow engine should be in the middle of the execution to orchestrate any steps involved with building a project. This is one of the places where people should be able to plug in their own steps and functionality. If someone is going down the plugin path, it
