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
Emmanuel
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
