continuum-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luc Willems" <luc.w...@gmail.com>
Subject Re: adding new module in a Multi Module project build
Date Tue, 07 Oct 2008 07:23:09 GMT
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 <brett.porter@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 <luc.will@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message