You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by David Jackman <Da...@fastsearch.com> on 2005/07/01 17:25:42 UTC
RE: Maven, CruiseControl, multiple projects & Best Practices
1. You'll definitely need to jar:install each project at the very least.
Otherwise, the later projects won't be able to find their dependencies.
You may also discover a problem we've been seeing lately. Someone will
make a change to 'common' which also requires a change to 'server'.
They check in both changes at once, but CC doesn't know the
dependencies, so picks one to build arbitrarily. If it builds 'server'
first, it will fail because 'common' isn't updated yet. Eventually the
projects get built and everything is okay, but all the red flags get
annoying (and people start to ignore build failures as a matter of
course, which causes the real problems to go unfixed for longer periods
of time). It seems CC just isn't put together in a way that makes this
work well (it's really made for building large independent projects and
not smaller semi-dependent projects (like Maven projects)). Hopefully
Continuum will be able to address this issue (I haven't had the time to
look deeply into it yet).
2. I think the site generated by multiproject:site is the only way to
get it. And if you're going to do that, you should really re-think
point number 4 ("I don't want to treat it as one big project (i.e. have
CC monitor 'trunk') because building 'common' and 'component1' every
time would just waste cycles needlessly."). If you use multiproject to
build the complete site, then you're wasting more cycles trying to build
each project individually before the multiproject builds and pretty much
does it all over again. Plus if you switch to a multiproject build,
then you won't ever see the problem I described above, because the
single multiproject will always build everything in the correct order.
-----Original Message-----
From: Jamie Bisotti [mailto:jbisotti@gmail.com]
Sent: Thursday, June 30, 2005 2:23 PM
To: Maven Users List
Subject: Maven, CruiseControl, multiple projects & Best Practices
Assuming the following project layout:
sandbox/
trunk/
common/
project.xml
project.properties
component1/
project.xml
project.properties
server/
project.xml
project.properties
where:
- 'common' is a small collection of utility classes used by several
projects
- 'component1' depends on 'common'
- 'server' depends on 'common' and 'component1'
- They truly are separate pieces of code; 'common' will hardly ever
change; 'component1' will change occasionally, but not often; but
'server' will change quite a bit.
How, I think, I want CC to work:
1. There is a CC project, defined in my config.xml, which monitors the
'common' code and continuously builds it.
2. There is a CC project, defined in my config.xml, which monitors the
'component1' code and continuously builds it; this CC project also
watches the 'common' CC project and builds when it changes.
3. There is a CC project, defined in my config.xml, which monitors the
'server' code and continuously builds it; this CC project also watches
the 'common' and 'component1' CC projects and builds when they change.
4. I don't want to treat it as one big project (i.e. have CC monitor
'trunk') because building 'common' and 'component1' everytime would just
waste cycles needlessly.
Questions:
1. By default, the following goals get called: scm:update|clean
test|site:deploy. That works fine for 'common', but the other two
fail because they can't find common-1.0.jar. I know I can use
'jar:install' in place of 'test'; is that what others are doing?
2. I'd also like to have an aggregated site build. I'm thinking about
setting up a separeate CC 'site' project, which will watch 'common',
'component1' & 'server'. When it detects one of those has changed, it
will do a multiproject:site-deploy from 'trunk' (so, I will probably
leave the 'site:deploy' goal out of the other CC projects). Will that
work? Is there a better way?
Thanks in advance for any ideas/suggestions.
--
Jamie Bisotti
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven, CruiseControl, multiple projects & Best Practices
Posted by Paul Spencer <pa...@apache.org>.
Jamie,
1) CruiseControl processes project in the order they appear in the
configuration file, cruisecontrol.xml. Base on David's example, the
project should be present in the following order:
common
component1
server
2) CruiseControl can build a project when another project has been
successfully built. See the <buildstatus> tag in CruiseControl
documentation,
http://cruisecontrol.sourceforge.net/main/configxml.html#buildstatus .
Maven's CruiseControl plugin will add the <buildstatus> tag based on the
property maven.cruisecontrol.trigger.projects. In David's example the
property should be set as follows:
Project common:
maven.cruisecontrol.trigger.projects=""
Project component1:
maven.cruisecontrol.trigger.projects="common"
Project server:
maven.cruisecontrol.trigger.projects="component1"
In my environment, I have a CruiseControl machine whose job includes
rebuilding projects triggered by cvs checkins, or successful build of a
dependent project, and host the CruiseControl web site. The
CruiseControl user, on that machine, has it's own build.properties with
properties that are specific to that machine. Below are a few
properties I have set. (I am not in the office at the moment, so I do
not know the exact list.)
maven.cruisecontrol.config
maven.cruisecontrol.home
maven.cruisecontrol.buildresults.site
(properties used to deploy artifacts, jars and wars)
(properties used to deploy generated sites)
Although I have not configure this, I believe a Maven "multiproject"
project can be included in the build that will generate a multiproject
site including projects build by CruiseControl. This project would not
rebuild its subproject, just reference them. See the properties:
maven.multiproject.navigation=independent
maven.dashboard.rungoals=false
Paul Spencer
Jamie Bisotti wrote:
> Paul, can you elaborate on that a bit more?
>
> On 7/1/05, Paul Spencer <pa...@apache.org> wrote:
>
>>David,
>>Between the order of projects in the cruise control configuration file
>>and the value of each projects "maven.cruisecontrol.trigger.projects"
>>property, you can minimize the number of failed builds as described in #1.
>>
>>Paul Spencer
>>
>>
>>David Jackman wrote:
>>
>>>1. You'll definitely need to jar:install each project at the very least.
>>>Otherwise, the later projects won't be able to find their dependencies.
>>>You may also discover a problem we've been seeing lately. Someone will
>>>make a change to 'common' which also requires a change to 'server'.
>>>They check in both changes at once, but CC doesn't know the
>>>dependencies, so picks one to build arbitrarily. If it builds 'server'
>>>first, it will fail because 'common' isn't updated yet. Eventually the
>>>projects get built and everything is okay, but all the red flags get
>>>annoying (and people start to ignore build failures as a matter of
>>>course, which causes the real problems to go unfixed for longer periods
>>>of time). It seems CC just isn't put together in a way that makes this
>>>work well (it's really made for building large independent projects and
>>>not smaller semi-dependent projects (like Maven projects)). Hopefully
>>>Continuum will be able to address this issue (I haven't had the time to
>>>look deeply into it yet).
>>>
>>>2. I think the site generated by multiproject:site is the only way to
>>>get it. And if you're going to do that, you should really re-think
>>>point number 4 ("I don't want to treat it as one big project (i.e. have
>>>CC monitor 'trunk') because building 'common' and 'component1' every
>>>time would just waste cycles needlessly."). If you use multiproject to
>>>build the complete site, then you're wasting more cycles trying to build
>>>each project individually before the multiproject builds and pretty much
>>>does it all over again. Plus if you switch to a multiproject build,
>>>then you won't ever see the problem I described above, because the
>>>single multiproject will always build everything in the correct order.
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: Jamie Bisotti [mailto:jbisotti@gmail.com]
>>>Sent: Thursday, June 30, 2005 2:23 PM
>>>To: Maven Users List
>>>Subject: Maven, CruiseControl, multiple projects & Best Practices
>>>
>>>Assuming the following project layout:
>>>
>>>sandbox/
>>> trunk/
>>> common/
>>> project.xml
>>> project.properties
>>> component1/
>>> project.xml
>>> project.properties
>>> server/
>>> project.xml
>>> project.properties
>>>
>>>where:
>>> - 'common' is a small collection of utility classes used by several
>>>projects
>>> - 'component1' depends on 'common'
>>> - 'server' depends on 'common' and 'component1'
>>> - They truly are separate pieces of code; 'common' will hardly ever
>>>change; 'component1' will change occasionally, but not often; but
>>>'server' will change quite a bit.
>>>
>>>How, I think, I want CC to work:
>>>1. There is a CC project, defined in my config.xml, which monitors the
>>>'common' code and continuously builds it.
>>>2. There is a CC project, defined in my config.xml, which monitors the
>>>'component1' code and continuously builds it; this CC project also
>>>watches the 'common' CC project and builds when it changes.
>>>3. There is a CC project, defined in my config.xml, which monitors the
>>>'server' code and continuously builds it; this CC project also watches
>>>the 'common' and 'component1' CC projects and builds when they change.
>>>4. I don't want to treat it as one big project (i.e. have CC monitor
>>>'trunk') because building 'common' and 'component1' everytime would just
>>>waste cycles needlessly.
>>>
>>>Questions:
>>>1. By default, the following goals get called: scm:update|clean
>>>test|site:deploy. That works fine for 'common', but the other two
>>>fail because they can't find common-1.0.jar. I know I can use
>>>'jar:install' in place of 'test'; is that what others are doing?
>>>2. I'd also like to have an aggregated site build. I'm thinking about
>>>setting up a separeate CC 'site' project, which will watch 'common',
>>>'component1' & 'server'. When it detects one of those has changed, it
>>>will do a multiproject:site-deploy from 'trunk' (so, I will probably
>>>leave the 'site:deploy' goal out of the other CC projects). Will that
>>>work? Is there a better way?
>>>
>>>Thanks in advance for any ideas/suggestions.
>>>--
>>>Jamie Bisotti
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven, CruiseControl, multiple projects & Best Practices
Posted by Jamie Bisotti <jb...@gmail.com>.
Paul, can you elaborate on that a bit more?
On 7/1/05, Paul Spencer <pa...@apache.org> wrote:
> David,
> Between the order of projects in the cruise control configuration file
> and the value of each projects "maven.cruisecontrol.trigger.projects"
> property, you can minimize the number of failed builds as described in #1.
>
> Paul Spencer
>
>
> David Jackman wrote:
> > 1. You'll definitely need to jar:install each project at the very least.
> > Otherwise, the later projects won't be able to find their dependencies.
> > You may also discover a problem we've been seeing lately. Someone will
> > make a change to 'common' which also requires a change to 'server'.
> > They check in both changes at once, but CC doesn't know the
> > dependencies, so picks one to build arbitrarily. If it builds 'server'
> > first, it will fail because 'common' isn't updated yet. Eventually the
> > projects get built and everything is okay, but all the red flags get
> > annoying (and people start to ignore build failures as a matter of
> > course, which causes the real problems to go unfixed for longer periods
> > of time). It seems CC just isn't put together in a way that makes this
> > work well (it's really made for building large independent projects and
> > not smaller semi-dependent projects (like Maven projects)). Hopefully
> > Continuum will be able to address this issue (I haven't had the time to
> > look deeply into it yet).
> >
> > 2. I think the site generated by multiproject:site is the only way to
> > get it. And if you're going to do that, you should really re-think
> > point number 4 ("I don't want to treat it as one big project (i.e. have
> > CC monitor 'trunk') because building 'common' and 'component1' every
> > time would just waste cycles needlessly."). If you use multiproject to
> > build the complete site, then you're wasting more cycles trying to build
> > each project individually before the multiproject builds and pretty much
> > does it all over again. Plus if you switch to a multiproject build,
> > then you won't ever see the problem I described above, because the
> > single multiproject will always build everything in the correct order.
> >
> >
> >
> > -----Original Message-----
> > From: Jamie Bisotti [mailto:jbisotti@gmail.com]
> > Sent: Thursday, June 30, 2005 2:23 PM
> > To: Maven Users List
> > Subject: Maven, CruiseControl, multiple projects & Best Practices
> >
> > Assuming the following project layout:
> >
> > sandbox/
> > trunk/
> > common/
> > project.xml
> > project.properties
> > component1/
> > project.xml
> > project.properties
> > server/
> > project.xml
> > project.properties
> >
> > where:
> > - 'common' is a small collection of utility classes used by several
> > projects
> > - 'component1' depends on 'common'
> > - 'server' depends on 'common' and 'component1'
> > - They truly are separate pieces of code; 'common' will hardly ever
> > change; 'component1' will change occasionally, but not often; but
> > 'server' will change quite a bit.
> >
> > How, I think, I want CC to work:
> > 1. There is a CC project, defined in my config.xml, which monitors the
> > 'common' code and continuously builds it.
> > 2. There is a CC project, defined in my config.xml, which monitors the
> > 'component1' code and continuously builds it; this CC project also
> > watches the 'common' CC project and builds when it changes.
> > 3. There is a CC project, defined in my config.xml, which monitors the
> > 'server' code and continuously builds it; this CC project also watches
> > the 'common' and 'component1' CC projects and builds when they change.
> > 4. I don't want to treat it as one big project (i.e. have CC monitor
> > 'trunk') because building 'common' and 'component1' everytime would just
> > waste cycles needlessly.
> >
> > Questions:
> > 1. By default, the following goals get called: scm:update|clean
> > test|site:deploy. That works fine for 'common', but the other two
> > fail because they can't find common-1.0.jar. I know I can use
> > 'jar:install' in place of 'test'; is that what others are doing?
> > 2. I'd also like to have an aggregated site build. I'm thinking about
> > setting up a separeate CC 'site' project, which will watch 'common',
> > 'component1' & 'server'. When it detects one of those has changed, it
> > will do a multiproject:site-deploy from 'trunk' (so, I will probably
> > leave the 'site:deploy' goal out of the other CC projects). Will that
> > work? Is there a better way?
> >
> > Thanks in advance for any ideas/suggestions.
> > --
> > Jamie Bisotti
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Jamie Bisotti
Software Engineer
Lexmark International, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven, CruiseControl, multiple projects & Best Practices
Posted by Paul Spencer <pa...@apache.org>.
David,
Between the order of projects in the cruise control configuration file
and the value of each projects "maven.cruisecontrol.trigger.projects"
property, you can minimize the number of failed builds as described in #1.
Paul Spencer
David Jackman wrote:
> 1. You'll definitely need to jar:install each project at the very least.
> Otherwise, the later projects won't be able to find their dependencies.
> You may also discover a problem we've been seeing lately. Someone will
> make a change to 'common' which also requires a change to 'server'.
> They check in both changes at once, but CC doesn't know the
> dependencies, so picks one to build arbitrarily. If it builds 'server'
> first, it will fail because 'common' isn't updated yet. Eventually the
> projects get built and everything is okay, but all the red flags get
> annoying (and people start to ignore build failures as a matter of
> course, which causes the real problems to go unfixed for longer periods
> of time). It seems CC just isn't put together in a way that makes this
> work well (it's really made for building large independent projects and
> not smaller semi-dependent projects (like Maven projects)). Hopefully
> Continuum will be able to address this issue (I haven't had the time to
> look deeply into it yet).
>
> 2. I think the site generated by multiproject:site is the only way to
> get it. And if you're going to do that, you should really re-think
> point number 4 ("I don't want to treat it as one big project (i.e. have
> CC monitor 'trunk') because building 'common' and 'component1' every
> time would just waste cycles needlessly."). If you use multiproject to
> build the complete site, then you're wasting more cycles trying to build
> each project individually before the multiproject builds and pretty much
> does it all over again. Plus if you switch to a multiproject build,
> then you won't ever see the problem I described above, because the
> single multiproject will always build everything in the correct order.
>
>
>
> -----Original Message-----
> From: Jamie Bisotti [mailto:jbisotti@gmail.com]
> Sent: Thursday, June 30, 2005 2:23 PM
> To: Maven Users List
> Subject: Maven, CruiseControl, multiple projects & Best Practices
>
> Assuming the following project layout:
>
> sandbox/
> trunk/
> common/
> project.xml
> project.properties
> component1/
> project.xml
> project.properties
> server/
> project.xml
> project.properties
>
> where:
> - 'common' is a small collection of utility classes used by several
> projects
> - 'component1' depends on 'common'
> - 'server' depends on 'common' and 'component1'
> - They truly are separate pieces of code; 'common' will hardly ever
> change; 'component1' will change occasionally, but not often; but
> 'server' will change quite a bit.
>
> How, I think, I want CC to work:
> 1. There is a CC project, defined in my config.xml, which monitors the
> 'common' code and continuously builds it.
> 2. There is a CC project, defined in my config.xml, which monitors the
> 'component1' code and continuously builds it; this CC project also
> watches the 'common' CC project and builds when it changes.
> 3. There is a CC project, defined in my config.xml, which monitors the
> 'server' code and continuously builds it; this CC project also watches
> the 'common' and 'component1' CC projects and builds when they change.
> 4. I don't want to treat it as one big project (i.e. have CC monitor
> 'trunk') because building 'common' and 'component1' everytime would just
> waste cycles needlessly.
>
> Questions:
> 1. By default, the following goals get called: scm:update|clean
> test|site:deploy. That works fine for 'common', but the other two
> fail because they can't find common-1.0.jar. I know I can use
> 'jar:install' in place of 'test'; is that what others are doing?
> 2. I'd also like to have an aggregated site build. I'm thinking about
> setting up a separeate CC 'site' project, which will watch 'common',
> 'component1' & 'server'. When it detects one of those has changed, it
> will do a multiproject:site-deploy from 'trunk' (so, I will probably
> leave the 'site:deploy' goal out of the other CC projects). Will that
> work? Is there a better way?
>
> Thanks in advance for any ideas/suggestions.
> --
> Jamie Bisotti
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org