From continuum-dev-return-6608-apmail-maven-continuum-dev-archive=maven.apache.org@maven.apache.org Wed Feb 06 10:26:06 2008 Return-Path: Delivered-To: apmail-maven-continuum-dev-archive@www.apache.org Received: (qmail 71111 invoked from network); 6 Feb 2008 10:26:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Feb 2008 10:26:06 -0000 Received: (qmail 74527 invoked by uid 500); 6 Feb 2008 10:25:57 -0000 Delivered-To: apmail-maven-continuum-dev-archive@maven.apache.org Received: (qmail 74490 invoked by uid 500); 6 Feb 2008 10:25:57 -0000 Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: continuum-dev@maven.apache.org Delivered-To: mailing list continuum-dev@maven.apache.org Received: (qmail 74479 invoked by uid 99); 6 Feb 2008 10:25:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Feb 2008 02:25:57 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 124.108.96.113 is neither permitted nor denied by domain of rahul.thakur.xdev@gmail.com) Received: from [124.108.96.113] (HELO rel106.mail.aue.yahoo.com) (124.108.96.113) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 06 Feb 2008 10:25:40 +0000 Received: (qmail 22039 invoked by uid 1000); 6 Feb 2008 10:25:29 -0000 Received: from 124.108.96.73 by rel106.mail.aue.yahoo.com with SMTP; Wed, 06 Feb 2008 02:25:29 -0800 Received: (qmail 79876 invoked from network); 6 Feb 2008 10:25:28 -0000 Received: from unknown (HELO ?192.168.1.64?) (rahul.thakur@xtra.co.nz@219.89.3.166 with plain) by smtp104.tnz.mail.aue.yahoo.com with SMTP; 6 Feb 2008 10:25:28 -0000 X-YMail-OSG: JfGQkRsVM1kvD788.xjEfAdWUovEVHzalA7DKPTFJsiSlvdsjnX6xqt3uQVjVOTl3w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <47A98B17.2020708@gmail.com> Date: Wed, 06 Feb 2008 23:25:27 +1300 From: Rahul Thakur User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: continuum-dev@maven.apache.org Subject: Re: [Discussion] Continuum 2.0 Roadmap References: <74F6D09E-E6F8-4986-87D0-18149E9A65F4@apache.org> In-Reply-To: <74F6D09E-E6F8-4986-87D0-18149E9A65F4@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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 > >