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