Return-Path: Delivered-To: apmail-maven-continuum-dev-archive@www.apache.org Received: (qmail 50255 invoked from network); 9 Feb 2008 16:06:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Feb 2008 16:06:27 -0000 Received: (qmail 78016 invoked by uid 500); 9 Feb 2008 16:06:20 -0000 Delivered-To: apmail-maven-continuum-dev-archive@maven.apache.org Received: (qmail 77986 invoked by uid 500); 9 Feb 2008 16:06:20 -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 77975 invoked by uid 99); 9 Feb 2008 16:06:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 09 Feb 2008 08:06:20 -0800 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [80.202.4.58] (HELO osl1smout1.broadpark.no) (80.202.4.58) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 09 Feb 2008 16:05:33 +0000 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0JVZ00M0ABD6NVF0@osl1smout1.broadpark.no> for continuum-dev@maven.apache.org; Sat, 09 Feb 2008 17:05:30 +0100 (CET) Received: from walter2.lan ([80.202.68.77]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0JVZ0008MBD4VSE0@osl1sminn1.broadpark.no> for continuum-dev@maven.apache.org; Sat, 09 Feb 2008 17:05:30 +0100 (CET) Message-id: <47ADCF3C.3020800@apache.org> Date: Sat, 09 Feb 2008 17:05:16 +0100 From: =?ISO-8859-1?Q?Trygve_Laugst=F8l?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) To: continuum-dev@maven.apache.org Subject: Re: [Discussion] Continuum 2.0 Roadmap References: <47A02FCC.1070808@gmail.com> <47AAC02D.20404@apache.org> <47ABBEF2.7090204@gmail.com> In-reply-to: <47ABBEF2.7090204@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Rahul Thakur wrote: > > >>> 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 Leaner in what way? >> >> 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. I didn't mean to say that Continuum should support *multiple* languages, only that it should support *a* language. My point was that when people are to customize their server they shouldn't have to start an IDE to create plugin. It should be possible to just mock around with some plugin files on the command line. -- Trygve