On Apr 13, 2008, at 1:21 AM, Benjamin Bentmann wrote:
Brian E. Fox wrote:
I saw leave it as it is because that is the normal scenario and
the one
users are most likely to have. This way we see and fix the same
things
they will need.
+1. The reactor was meant for exactly those aggregating builds. The
usual way to disable recursive builds is the -N flag. If that's
causing problems with the Release Plugin, we should fix the cause,
not the symptom.
Really? I think the situation in plugins bears closer examination.
It seems to me that both the reactor and release plugin work best
with groups of projects where the directory layout matches the pom
inheritance. This is decidedly NOT the case in plugins, as the
parent pom for each plugin is a released version of the parent, not
the version in the parent directory. Clearly in such an environment
releasing the entire tree at once is not intended and the build
should be set up to make sure it doesn't happen.
The current setup combines two completely separate functions:
1. providing a single parent pom for all the plugins: normally each
plugin in trunk will use a (possibly different) released version of
the parent pom as parent, and never the snapshot version above it in
the directory tree.
2. providing a convenience method of building all the plugins at
once. This should never be activated when releasing the parent pom.
Unless you are running a CI setup or looking for regressions from
activity elsewhere you almost certainly don't want to run this build.
The current setup mixes up these two functions and IIUC trying to
release the parent will activate building and probably releasing all
the individual plugins. I know of two easy ways to separate these
two unrelated functions:
a. Put the parent pom somewhere else, like in plugins/trunk/plugin-
parent. The pom in plugins/trunk would just have the modules element.
b. Put the list of modules in a profile where the release plugin
won't see it.
I prefer (a) because then tagging the parent pom wont copy the entire
set of plugins in a unreleased state into the svn tag for the
released parent pom which in my view creates unnecessary confusion
for anyone trying to understand what's going on in svn.
Are there any other situations where having the release plugin ignore
the modules element would be appropriate?
thanks
david jencks
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
