continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Venisse <>
Subject Re: Proposition for CONTINUUM-798
Date Wed, 11 Jul 2007 07:51:44 GMT

Brett Porter a écrit :
> This sounds fine to me.
> Questions I think weren't answered here:
> - how do you track when the modules change - by comparing <modules> to 
> the list of projects in a group? If so, how to handle the edge cases 
> where extra projects are added to or removed from a group aside from the 
> modules?
> - how do you handle the removal of a module from a POM when the project 
> is still in Continuum? Will that just delete the project, and if so what 
> happens to the build history, etc.? (sounds dangerous!)

I don't think we should delete projects that are already in Continuum, it should be a manual
opration done by a group admin.

> Would you be able to write this up as a short proposal on the website?

Yes, please.

> The only other thought I have is that this is a new feature - is it 
> intended to land before 1.1-beta-1, or will it be on a feature branch 
> for a later version of Continuum?

I'd prefer to see it in a branch and integrate it in 1.2. This new feature will modify the
database and I don't want to see an other db schema change before 1.1 final

> Cheers,
> Brett
> On 11/07/2007, at 4:40 PM, Maria Odea Ching wrote:
>> Hi All,
>> I'm trying to fix up, 
>> which is "Modules automatic discovery". I think the patch submitted is 
>> already outdated and there was the issue about recursive modules.
>> Anyway, below is how I thought to implement the fix for this:
>> Create an "update-modules" action in continuum-core that will check 
>> for new modules in the pom. The action would be invoked when a project 
>> build is triggered (forced or scheduled), after the project is updated 
>> from SCM (in DefaultBuildController).
>> To add the new module to Continuum, I think we could make use of the 
>> addMavenTwoProject(..) method in DefaultContinuum. We can derive the 
>> required parameters from the parent project. The metadata url can be 
>> gotten from the SCM url of the parent  (since the SCM urls of modules 
>> are just constructed from the parent project's SCM url by inserting 
>> the module's name in the url). The group id can also be derived from 
>> the parent project, as well as the SCM username and SCM password.
>> Then after the module is added and checked-out.. the project can just 
>> be added in the build queue so that it will be included in the 
>> triggered build.
>> From the above implementation, I think we can recurse even through the 
>> modules if they are multi-module projects as well.
>> What do you guys think? Any thoughts would be greatly appreciated :-)
>> Thanks,
>> Deng

View raw message