My observations until now (working 2 month with continuum) i have a feeling that multi module Maven 2 projects are handled like multi "single" projects with some magic. This can be obserbed by the way the projects are checkout in the working directory , each project seperated directory, flat structure , and de way the projects run (build queue is filled with single "projects" in a order).
this way of working leads to some problems as we can find in different JIRA issues. The current state is that is doesn't work the same like running a multi module project in cli. So to prevent some of these problems we should look closely the way Maven2 cli does it and follow this closely. some thing i could suggest for improvement are : - when a multi Module project is imported, the Parent POM is the master and defines the build parameters (environment, schedule,etc ). It should be clear in the project overview what the parent is and what the submodules is (like a directory structure). - All sub modules are "virtual" projects that are run based on LATEST info of parent POM (module list) & maven dependency policy. Latest means having a way to update this list (add/remove/change) based on latest SCM pom.xml of the parent. Virtual means . they inhire build configuration of the parent but can be runned seperated if needed. all build result/report are stored seperated so that overview is not lost in big projects. - When you checkout the project from a SCM system , checkout in 1 directory for the complete project. now all sub projects are separated , giving problems because the structure of the project is not respected. there are different JIRA about not able to do .../some_parent_file. - keep de option to run only sub modules if they change. additionaly it would be nice to also build project date depend an the changed module. - Release based in Parent POM and a release envirment setting. Also give result of testing reports visuable (this is not the case at this moment, i think) These problebly means , complete redesign of current maven2 support so not a option for 1.2.x or even 1.x but i think it would be a better and prevent issues like "it's works on cli, but not in continuum because of ...." at the end of the day it would be good that continuum would run equally as CLI maven2 + some smart feature to organize results just my 2 cent On Tue, Oct 7, 2008 at 2:14 AM, Brett Porter <[EMAIL PROTECTED]> wrote: > It sounds like a bug that Continuum is not adapting the order due to > the dependencies as it goes. > > I know we are looking at ways to more smartly handle modules in the future. > > - Brett > > 2008/10/6 Luc Willems <[EMAIL PROTECTED]>: > > Hello all > > > > i have some issues using a multi module project : > > > > we have a project like : > > project > > + module A > > + module B > > + module C > > + module D > > > > module D needs a,b & c . project is imported so that we have 5 build > > projects (project +A,B,C,D) > > > > when this project is imported and initial build is started , a correct > Queue > > order is respected so > > that first the project is build , than A,B,C and than D. so far so good > > > > no we introduced a new module Z , which is used by ALL sub modules > (A,B,C,D) > > > > first problem : module Z is never imported into the contiuum build. there > is > > also no option to "Update" the > > project so that the new Z module is imported in the project list > > > > Second problem : add module Z manually to project. now when i build the > > project , Z isn't build after > > the project pom (like it would be done in a cli maven environment) but > based > > on "ascii" order , in this case > > last. > > > > because of dependencies , A,B,C,D will fail . > > > > alternative : delete all build definitions and re-import project pom.xml > so > > Z is integrated and build in correct order. by deleting the build > > confirations , we also lose "old" build information (test results ...) > > > > Is there a better whay to handle this. I know i can import a multi module > > project as 1 build but this > > eliminates the options to "smartly" only build what has changed. > > > > > > > > -- > > Willems Luc > > Email : Luc Willems <luc.will(at)gmail.com> > > > > We the unwilling, > > led by the unknowing, > > are doing the impossible > > for the ungrateful. > > We have done so much for so long with so little > > We are now qualified to do anything with nothing > > > > see http://www.perl.com/pub/a/2003/07/16/soto2003.html?page=1 > > > > > > -- > Brett Porter > Blog: http://blogs.exist.com/bporter/ > -- Willems Luc Email : Luc Willems <luc.will(at)gmail.com> We the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much for so long with so little We are now qualified to do anything with nothing see http://www.perl.com/pub/a/2003/07/16/soto2003.html?page=1
