We have a scheme like some that have been mentioned,
in which the system is broken into modules and building the
system means looping through the modules applying the
same build script to each. The build of each module is
broken down into phases, e.g., assemble, compile,
create-jar, test, etc (that aspect is fairly Mavenish, I think).
Each phase has at least 4 targets: the composite public one, the
mandatory default implementation, and the empty, but overridable
by each module, before and after hooks, e.g.:
<target name="compile"
depends="assemble,compile-before,compile-default,compile-after"/>
We are pushing 500 modules now, with a hundredish developers,
many of them determined (it sometimes seems) to abuse any and all
provided customization points.
Consequently, my main comment (apologies if I missed it in the thread)
is that any magic target overriding feature needs to balanced by
a target locking feature, for at least two reasons: (1) the integrity of
the
build depends on certain chunks of script (typically in the xxx-default
targets) always being invoked and (2) nobody can understand and
manage a build of 500 modules if modules do their own thing even for
basic tasks like compiling and creating jars.
A corollary is that if I were to base this system on the hypothesized
Ant-supplied system, I expect I would need to customize quite a bit,
but I would not want to expose most of that customizability to the
modules. (Perhaps that is something like what Gilles was thinking
when he mentioned two levels of customization?)
Regards,
Louis Tribble
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
