You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@continuum.apache.org by Maria Odea Ching <oc...@exist.com> on 2007/07/11 08:40:56 UTC
Proposition for CONTINUUM-798
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
Re: Proposition for CONTINUUM-798
Posted by Maria Odea Ching <oc...@exist.com>.
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
Re: Proposition for CONTINUUM-798
Posted by Maria Odea Ching <oc...@exist.com>.
Sorry, I didn't see these before I sent my last email. Anyway, I guess
some of the things I wrote there was already answered in the thread :-)
-Deng
Emmanuel Venisse wrote:
>
>
> Brett Porter a écrit :
>>
>> On 11/07/2007, at 5:51 PM, Emmanuel Venisse wrote:
>>
>>>
>>>
>>> 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.
>>
>> I agree - what I'm wondering is how the group admin knows to do so
>> (for now, a simple email should probably suffice).
>
> agree. Wed can add too a "ToDo" page that list actions to do. The
> admin can accept or refused the action.
> In this page we'd can list all actions done on a group (project
> added/deleted/modified, the user that done the action...), but it is
> an other feature :)
>
> Emmanuel
>
>
>
Re: Proposition for CONTINUUM-798
Posted by Emmanuel Venisse <em...@venisse.net>.
Brett Porter a écrit :
>
> On 11/07/2007, at 5:51 PM, Emmanuel Venisse wrote:
>
>>
>>
>> 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.
>
> I agree - what I'm wondering is how the group admin knows to do so (for
> now, a simple email should probably suffice).
agree. Wed can add too a "ToDo" page that list actions to do. The admin can accept or refused the action.
In this page we'd can list all actions done on a group (project added/deleted/modified, the user that done the action...), but it is an other feature :)
Emmanuel
Re: Proposition for CONTINUUM-798
Posted by Brett Porter <br...@apache.org>.
On 11/07/2007, at 5:51 PM, Emmanuel Venisse wrote:
>
>
> 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.
I agree - what I'm wondering is how the group admin knows to do so
(for now, a simple email should probably suffice).
- Brett
Re: Proposition for CONTINUUM-798
Posted by Emmanuel Venisse <em...@venisse.net>.
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
>
>
>
Re: Proposition for CONTINUUM-798
Posted by Maria Odea Ching <oc...@exist.com>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Proposition for CONTINUUM-798
Posted by Brett Porter <br...@apache.org>.
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!)
Would you be able to write this up as a short proposal on the website?
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
Re: Proposition for CONTINUUM-798
Posted by Emmanuel Venisse <em...@venisse.net>.
Maria Odea Ching a écrit :
> Hi Olivier,
>
> I think CONTINUUM-798 is for automatic discovery of new modules of a
> project that is already in Continuum. The current setup is that when
> Continuum updates from svn, the module is not added as a separate
> project. Considering CONTINUUM-774, this should only be done if the
> automaticAddChildModules parameter is set to true right? :-)
Yes, this parameter will be set during the project initialisation, based on the field "load only root as recursive build". It will be possible to modify it in the edit project screen too.
Emmanuel
>
> Thanks,
> Deng
>
> LAMY Olivier wrote:
>> Hi,
>> IMHO, this can't be "automatic" because CONTINUUM-774 has been fixed.
>> If you use this option this means you don't want to checkout child
>> modules as a separate project even if it's a new module.
>> A parameter could be add (at the project level) to say something
>> "automaticAddChildModules" or an other name ;-).
>>
>> --
>> Olivier
>> -----Message d'origine-----
>> De : Maria Odea Ching [mailto:oching@exist.com] Envoyé : mercredi 11
>> juillet 2007 08:41
>> À : Maven Developers List; continuum-dev@maven.apache.org
>> Objet : Proposition for CONTINUUM-798
>>
>> 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
>>
>>
>> This e-mail, any attachments and the information contained therein
>> ("this message") are confidential and intended solely for the use of
>> the addressee(s). If you have received this message in error please
>> send it back to the sender and delete it. Unauthorized publication,
>> use, dissemination or disclosure of this message, either in whole or
>> in part is strictly prohibited.
>> **********************************************************************
>> Ce message électronique et tous les fichiers joints ainsi que les
>> informations contenues dans ce message ( ci après "le message" ), sont
>> confidentiels et destinés exclusivement à l'usage de la personne à
>> laquelle ils sont adressés. Si vous avez reçu ce message par erreur,
>> merci de le renvoyer à son émetteur et de le détruire. Toutes
>> diffusion, publication, totale ou partielle ou divulgation sous
>> quelque forme que se soit non expressément autorisées de ce message,
>> sont interdites.
>> **********************************************************************
>>
>>
>
>
>
>
Re: Proposition for CONTINUUM-798
Posted by Maria Odea Ching <oc...@exist.com>.
Hi Olivier,
I think CONTINUUM-798 is for automatic discovery of new modules of a
project that is already in Continuum. The current setup is that when
Continuum updates from svn, the module is not added as a separate
project. Considering CONTINUUM-774, this should only be done if the
automaticAddChildModules parameter is set to true right? :-)
Thanks,
Deng
LAMY Olivier wrote:
> Hi,
> IMHO, this can't be "automatic" because CONTINUUM-774 has been fixed.
> If you use this option this means you don't want to checkout child modules as a separate project even if it's a new module.
> A parameter could be add (at the project level) to say something "automaticAddChildModules" or an other name ;-).
>
> --
> Olivier
>
> -----Message d'origine-----
> De : Maria Odea Ching [mailto:oching@exist.com]
> Envoyé : mercredi 11 juillet 2007 08:41
> À : Maven Developers List; continuum-dev@maven.apache.org
> Objet : Proposition for CONTINUUM-798
>
> 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
>
>
> This e-mail, any attachments and the information contained therein ("this message") are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited.
> **********************************************************************
> Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après "le message" ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites.
> **********************************************************************
>
>
>
RE: Proposition for CONTINUUM-798
Posted by LAMY Olivier <Ol...@accor.com>.
Hi,
IMHO, this can't be "automatic" because CONTINUUM-774 has been fixed.
If you use this option this means you don't want to checkout child modules as a separate project even if it's a new module.
A parameter could be add (at the project level) to say something "automaticAddChildModules" or an other name ;-).
--
Olivier
-----Message d'origine-----
De : Maria Odea Ching [mailto:oching@exist.com]
Envoyé : mercredi 11 juillet 2007 08:41
À : Maven Developers List; continuum-dev@maven.apache.org
Objet : Proposition for CONTINUUM-798
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
This e-mail, any attachments and the information contained therein ("this message") are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited.
**********************************************************************
Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après "le message" ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites.
**********************************************************************