Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: continuum-dev@maven.apache.org
Received-SPF: pass (athena.apache.org: domain of
 gcjcd-continuum-dev@m.gmane.org designates 80.91.229.2 as permitted sender)
To: continuum-dev@maven.apache.org
From: ossi petz <ossipetz@hallo.ms>
Subject: Re: Continuum 1.2 Roadmap
Date: Thu, 11 Oct 2007 16:54:50 +0200
Lines: 80
Message-ID: <feldfq$ckj$1@sea.gmane.org>
References: <41950.195.8.80.1.1191441864.squirrel@webmail.venisse.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
In-Reply-To: <41950.195.8.80.1.1191441864.squirrel@webmail.venisse.net>
Sender: news <news@sea.gmane.org>

Hallo there

roadmaps are a good thing!

Emmanuel Venisse schrieb:
> - Rewrite all the UI with a full GWT site. I want to migrate to GWT
> because we need better performance on the UI even if it is correct now.
> The second point is that with GWT (and Ajax in general)
 >
i dont know that much about gwt. i would recommend to stuck with a web 
framework found at apache.org. wicket, tapestry or one of the other 120? 
i dont see license trouble but well: political correctness? :)

in the end i have preferred framework.

some tweaks on the gui may not be that wrong. it looks nice but it has 
some 'search and try and click' tendency. but as mentioned thats more 
marketing. i vote for stronger more stable build support (see below).


> - Better support of XML-RPC and other remote access (XFire, ...). For this
> point, I think it would be good to share the code with the GWT part with
> some services classes that will embed all the
> "remote" code with security checks
> 

sounds good too. at some point some eclipse integration / plugin would 
be something. that would allow a good starting point.


> - Better support of maven projects. Actually, we detect if a build is
> required by looking at scm changes and dependencies changes. The problem
> is in dependencies changes. We look only at dependencies
> that are a continuum project too, it would be good to check repositories
> to find if a new version exists like maven do it. An other problem with
> dependencies changes is we don't really check if a new
> version exists but only if a new build result was created, it's a problem
> in case of projects with more than one build definition (for example
> "clean install" and "site"). If a site is generated, a
> new build result is created and continuum consider it as a dependency
> change so it rebuild all dependent projects in the next step.
> 

that will be the more important part :)
what i currently miss are clearer build dependencies. i think its pretty 
difficult to actually determine the correct build order automatically. 
so i would like to have the possibility to create some sort of 'build 
tree'. a build would be starting at the root of the tree going downwards 
building the projects.
our projects often depend on each other. sometimes the change in one 
module triggers the build of another project mutliple times (if a third 
module was triggered too). a tree like structure would allow to keep 
some order while not loosing some overview of the dependencies and help 
to avoid re-re-rebuilds of the same modules.

also a fueature request like 'planned release' would be cool. so a 
release could be planned for some date. continuum could then create the 
release on its own on a week end. this is an issue since one release may 
require the release of dependant porjects (see build tree thing). and 
with all reports and stuff this takes ages.

at the moment we dont need clustering. installing multiple servers does 
the job for us.


i've seen in bamboo that it is collection certain statistical 
information (build time, failed builds, time to fix tests). such 
features would be a nice to have. but it would require reporting over 
mutliple projects to make any sense.


hope to gave you some ideas :)


thanks a lot!
regards

ossi