ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject RE: ant 1.5.4 : Import
Date Tue, 29 Jul 2003 14:11:57 GMT
> -----Original Message-----
> From: Stefan Bodewig []
> > For example, let's say I have a compile target I want to import, and
> > I want to make it additionally call the "pre" target before and the
> > "post" target after.
> Then you don't want to import the target but a different target IMHO.

I disagree ;-)

One of my major hope in that import will enable me to keep the same build
file API (the targets available to call) across many projects, while being
flexible enough to adapt to each project's peculiarities, and
reuse/centralize as much as possible of the commonalities in the importable
build file.

Basically I want the Template Method pattern, which requires
override-ability (it's not a word apparently ;-) of methods, or targets in
this context.

I have two goals:

1) Being able to add pre and/or post processing to an existing target
imported. That's what Maven does, and it's quite powerful. Like Nicola Ken,
I do not want to have to rename the original target (my goal of keeping the
build API consistent, which is very important to my colleagues!)

2) Being able to completely override the default behavior of an imported

If I recall correctly, Knut (Wannheden) implemented this using XSL and a
<super> keyword. I don't really care how my personal goals outlined above
are achieved implementation-wise, but I do hope <import> would fulfill them.

It doesn't mean that we shouldn't also have an <include>, like XSL does,
that basically the same as <import> but errors out in case of any conflicts.
Actually, would probably make sense to start with <import>, and then add
target overriding on top for <import> IMHO.

Thanks, --DD

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

View raw message