continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maria Odea Ching <och...@exist.com>
Subject Re: Proposition for CONTINUUM-798
Date Wed, 11 Jul 2007 08:42:46 GMT
Hi Brett,

Please see in-line comments below :-)


Brett Porter wrote:
> 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?
Originally, what I intended to do here was get the <modules> in the 
updated POM and then compare this with the <modules> in the old POM to 
identify the new modules and add them as separate projects to Continuum. 
I forgot about the extra projects that can be added to or removed from a 
group. Now that you've mentioned it, I think the proper way would be to 
compare the <modules> of the updated POM with all the projects in the 
Project Group. If the project already exists, then it wouldn't be 
checked out and added to Continuum anymore. Otherwise, it would be 
checked out, added as a separate project in Continuum and included in 
the build. The extra projects removed from the Project Group should no 
longer be a concern here since it is not in the database anymore.
> - 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 think removed modules from the POM should not be removed in Continuum 
so that the build history can still be accessed or viewed. In any case, 
it wouldn't be included in the build when a build is triggered in the 
parent. What I think can be done here instead is to have it flagged as 
removed or deleted from pom so that the Continuum user would be aware of it.
>
> Would you be able to write this up as a short proposal on the website?
>
I can write this up at the website. Should I do this at Continuum's wiki?
> 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?
>
> Cheers,
> Brett
>
> On 11/07/2007, at 4:40 PM, Maria Odea Ching wrote:
>
>> Hi All,
>>
>> I'm trying to fix up http://jira.codehaus.org/browse/CONTINUUM-798, 
>> 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

Thanks,
Deng

Mime
View raw message