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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
