You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@continuum.apache.org by Luc Willems <lu...@gmail.com> on 2008/10/06 14:10:26 UTC
adding new module in a Multi Module project build
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
Re: adding new module in a Multi Module project build
Posted by Luc Willems <lu...@gmail.com>.
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 <br...@gmail.com> 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 <lu...@gmail.com>:
> > 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
Re: adding new module in a Multi Module project build
Posted by Brett Porter <br...@gmail.com>.
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 <lu...@gmail.com>:
> 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/