Dominique Devienne wrote:
On 1/15/08, Louis Tribble <[EMAIL PROTECTED]> wrote:
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.
This is interesting. So you want some kind of "final" keyword for a
target, to allow controlled customization only, right? Basically the
template method pattern, with an immutable public target, and only
limited customization.
Right. In fact, we were very conscious of applying design
patterns to the build system.
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?)
That's where I'm confused. You want to be able to customize in some
places, but not in others??? I don't quite follow what you mean here.
Sorry if I wasn't clear. Xavier was suggesting (in part) a set
of reusable build scripts. To be useful, those scripts need to
be customizable in a variety of ways, which led to the
discussion of super and before/after and so on. I was noting
that if we were to implement our build system on top of these
reusable scripts, we no doubt would be stretching the
customization hooks to their limit, but we will want to significantly
limit what individual module developers can customize.
A couple of particulars that come to mind with our
compile-default target:
The sourcepath, classpath, and output directory for
each module are dictated by the build system, not the
module (so we would want to configure that, but not
let module developers reconfigure it).
Before the actual compile, we convert the property files
containing translateable resources to Java files and maintain
a list of all files needing translation (the translation team,
which services the entire company, uses that list to drive
their translations).
In the postulated reusable script scenario, our standard resource
preprocessing would presumably be plugged in to the
public distribution as a before target. We want to allow
modules to provide their own before targets, but not allow
them to mess with our standard one.
(Actually, while I'm at it, we reflexively provided before and
after targets for the test phase, which seems to have been a
mistake. The chief use has been to set up test
fixtures (starting and stopping web servers, etc), which
would have been more robust and reusable if done from
within the JUnit test classes.)
Louis
--DD
---------------------------------------------------------------------
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]
