> -----Original Message-----
> From: Brekke, Jeff [mailto:[EMAIL PROTECTED]]
> Sent: 21 May 2002 19:22
> To: 'Turbine Maven Users List'
> Subject: RE: Using maven on a project with sub-projects
> 
> Yea I remember the multi-project stuff mentioned on the CC list also.
> Currently if one thing fails, the entire build is in failure and must
be
> fixed.  We have cc generate an email on failure.  Again, we have
> subprojects, but CC is treating this as one big project.  We also tag
in
> cvs
> and deploy on every sucessfull build.  This is dependant on cvs
activity
> for
> the day, but on an average we have about 7-10 builds per day.  Every
10
> sucessful builds we run through our integration unit tests ( unit test
are
> run on every build ).  

Yeah there are some nice features in CC like the CVS check task that
verifies if there has been no activity for the past xx minutes, the full
build every N builds, etc. that are not in built-in Gump.

What we need is a way to script Gump. For the moment the Gump
descriptors defines project data. We need a way to tell Gump how to use
these data. I think a good solution in the future would be to use Jelly
for this ... (don't you think James :-) ?).

WRT to the builds we do continuous Gump builds all the time. In practice
that's every 15 minutes and we run the full tests (logic unit tests,
integration unit tests and functional unit tests).

ATM it is a bit of a pain to have to maintain project build information
in 2 places : once in the Ant build and once in the Gump descriptor. We
often modify the project build and forget to modify the Gump descriptors
...

Maven might help there by having only a single project descriptor ...

-Vincent

> It is working nicely for us, but with the mix of
> webapps, torque generation, unit vs iutests, and databases our
hand-made
> build system is a terrible mess.  This is where maven hopefully will
help
> us
> level the builds across subprojects.
> 
> =================================================================
> Jeffrey D. Brekke                                   Quad/Graphics
> [EMAIL PROTECTED]                              http://www.qg.com
> 
> 
> > -----Original Message-----
> > From: Vincent Massol [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, May 21, 2002 1:08 PM
> > To: 'Turbine Maven Users List'
> > Subject: RE: Using maven on a project with sub-projects
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Brekke, Jeff [mailto:[EMAIL PROTECTED]]
> > > Sent: 21 May 2002 18:47
> > > To: 'Turbine Maven Users List'
> > > Subject: RE: Using maven on a project with sub-projects
> > >
> > > I believe there is work within maven that generates a gump
> > descriptor
> > for
> > > a
> > > maven controlled project ( but I don't know much about gump
> > anymore ).
> > > I tried to use gump last year before trying CC.  I never could
quite
> > come
> > > to
> > > terms with the implementation.  Maybe I'm just not a sharp enough.
> >
> > Yes, it is a bit difficult to start with. But once you get
> > over that, it
> > is quite nice and actually easy to use. By the way, how do you
report
> > individual project failure with your system ? in Gump a
> > project can fail
> > but the other can still build fine (unless they need this sub
> > project in
> > which case it is clearly shown in the log that it failed because of
a
> > pre req missing). How do you generate per-project emails, etc ?
> >
> > That's what made us change from CC to Gump. But I'm sure the
> > CC guys are
> > working towards a multi-project solution (I think I remember the
main
> > CCcommitter mentioning this some time ago).
> >
> > >
> > > I am very interested in the multi-project aspect of Continous
> > Integration.
> > > The reactor work is along the lines of what we have here for our
> > > multi-project build.  We just hardcode the order of builds by hand
> > > currently
> > > and let CC kick of the builds when stuff changes in cvs.
> > >
> > > =================================================================
> > > Jeffrey D. Brekke                                   Quad/Graphics
> > > [EMAIL PROTECTED]                              http://www.qg.com
> > >
> > >
> > > > -----Original Message-----
> > > > From: Vincent Massol [mailto:[EMAIL PROTECTED]]
> > > > Sent: Tuesday, May 21, 2002 11:39 AM
> > > > To: 'Turbine Maven Users List'
> > > > Subject: RE: Using maven on a project with sub-projects
> > > >
> > > >
> > > > Hi Jeff,
> > > >
> > > > We dropped CruiseControl in favor of GUMP so that we are now
> > > > able to do
> > > > project builds "separately" (which is the problem with CC -
> > > > it considers
> > > > only one project and you can't really have several CC
> > running if the
> > > > projects are dependent upon each other). We're prototyping
> > > > Maven and we
> > > > would probably be able to generate the Gump descriptors
> > automatically
> > > > from the Maven ones.
> > > >
> > > > -Vincent
> > > >
> > > > > -----Original Message-----
> > > > > From: Brekke, Jeff [mailto:[EMAIL PROTECTED]]
> > > > > Sent: 21 May 2002 15:52
> > > > > To: 'Turbine Maven Users List'
> > > > > Subject: RE: Using maven on a project with sub-projects
> > > > >
> > > > > We also have a situation similar to your project/subproject
> > system.
> > > > I've
> > > > > been viewing each as its own project as you indicate.
> > But we are
> > > > using
> > > > > continuous integration so the dependencies are important
> > > > every time we
> > > > > build
> > > > > our sources.  We build our sources every time someone
> > > > commits a change
> > > > in
> > > > > cvs.
> > > > >
> > > > > The way you describe your dependencies below it sounds like
you
> > want
> > > > > continuous integration of multiple projects.  Something
> > > > that Maven and
> > > > > Cruise Control ( what we are currently using ) don't offer
> > > > currently.
> > > > > There
> > > > > is work being done in maven to create this meta-build.  It is
> > called
> > > > the
> > > > > 'Reactor' and basically looks at your projects dependencies
and
> > > > creates a
> > > > > build script to build the projects in the correct dep
> > > > order.  The idea
> > > > > then
> > > > > is to use this meta-build in a continuous integration
> > > > environment for
> > > > > projects.  This is still very much work in progress.
> > > > >
> > > > > I am in the same boat as you.  My current plan ( if I get
> > > > time ) is to
> > > > > convert each project to use maven itself in a single
> > > > process sense and
> > > > > author this meta-build by hand at this time.
> > > > >
> > > > >
> > =================================================================
> > > > > Jeffrey D. Brekke
> > Quad/Graphics
> > > > > [EMAIL PROTECTED]
> > http://www.qg.com
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: James Macgill [mailto:[EMAIL PROTECTED]]
> > > > > > Sent: Tuesday, May 21, 2002 8:13 AM
> > > > > > To: [EMAIL PROTECTED]
> > > > > > Subject: Using maven on a project with sub-projects
> > > > > >
> > > > > >
> > > > > > Hi
> > > > > >
> > > > > > I've been reading through the maven site and it looks like
> > > > > > the tool is
> > > > > > exactly what I need to manage the build process for
GeoTools2,
> > an
> > > > > > opensource project that I coordinate.
> > > > > >
> > > > > > I hope no-one minds, but because the directory structure of
> > > > > > geotools is a
> > > > > > little unusual I'd like some advice before go any further.
> > > > > >
> > > > > > For anyone familiar with it, the structure we are using is
> > > > > > based loosely on
> > > > > > the structure used in the NetBeans CVS repository.  If
you're
> > > > > > not then the
> > > > > > basic principal is that the project as a whole is split into
> > > > > > a number of
> > > > > > modules, or sub-projects.
> > > > > >
> > > > > > A, slightly out of date, overview can be seen here:
> > > > > >
http://www.geotools.org/modules.php?op=modload&name=Sections&f
> > > > > > ile=index&req=viewarticle&artid=18&page=1
> > > > > >
> > > > > > In effect each module in the cvs is the equivalent of
maven's
> > > > > > concept of a
> > > > > > project.  They have their own maintainers, dependencies,
task
> > > > > > tracker, home
> > > > > > page and documentation.  At the moment each module
> > can be built
> > > > > > independently (automatically building other modules as
> > > > > > needed) or managed
> > > > > > centrally by a 'dummy' gtbuild module.
> > > > > >
> > > > > > Ideally I would like each module to be a maven project, but
I
> > > > > > don't want to
> > > > > > loose the recursive dependency checks.  i.e. if I module C
> > > > > > depends on B and
> > > > > > B depends on A and A depends on another projects jar X then
> > > > > > at the moment
> > > > > > any attempt to build C will build B and A and copy X.jar .
> > > > > > From what I can
> > > > > > see from the documentation maven 'depends' will not let
> > > > me do this.
> > > > > >
> > > > > > I'm very keen to switch to maven and to stop re-inventing
the
> > > > > > wheel, any
> > > > > > advice on how it can be used to manage sub-projects within a
> > > > > > single project
> > > > > > would be much appreciated. All of the files are stored in a
> > > > > > single cvs
> > > > > > repository, and if it helps anyone to know what on earth I'm
> > > > > > going on about
> > > > > > you can take a look at:
> > > > > >
> > > > > >
> > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/geotools/geotools2/
> > > > > >
> > > > > > Apologies again for the length of this email and for my lack
> > > > > > of knowledge
> > > > > > of all this maven.  Still, if we switch to maven then I can
> > > > > > see myself
> > > > > > becoming an active participant in its development.
> > > > > >
> > > > > > Many thanks in anticipation
> > > > > >
> > > > > > James
> > > > > >
> > > > > > --
> > > > > > James Macgill
> > > > > > Center for Computational Geography
http://www.ccg.leeds.ac.uk
> > > > > > Spell Checker (c) Creative Spelling inc (aka my
> > dyslexic brain)
> > > > > > http://www.geotools.org a client side java mapping toolkit.
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > <mailto:[EMAIL PROTECTED]>
> > > > > For additional commands, e-mail:
> > > > > <mailto:[EMAIL PROTECTED]>
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:   <mailto:turbine-maven-user-
> > > > > [EMAIL PROTECTED]>
> > > > > For additional commands, e-mail: <mailto:turbine-maven-user-
> > > > > [EMAIL PROTECTED]>
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > >
> > > --
> > > To unsubscribe, e-mail:   <mailto:turbine-maven-user-
> > > [EMAIL PROTECTED]>
> > > For additional commands, e-mail: <mailto:turbine-maven-user-
> > > [EMAIL PROTECTED]>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> 
> --
> To unsubscribe, e-mail:   <mailto:turbine-maven-user-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:turbine-maven-user-
> [EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to