ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Louis Tribble <>
Subject Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Date Tue, 15 Jan 2008 22:16:07 GMT
Dominique Devienne wrote:
> On 1/15/08, Louis Tribble <> 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.)


> --DD
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message