ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: Expressing BuildListeners (was Re: [Ant2] Tasks as siblings of <target>)
Date Tue, 06 Nov 2001 15:49:24 GMT
From: "Stefan Bodewig" <>

> On Mon, 5 Nov 2001, Jose Alberto Fernandez <>
> wrote:
> > One of the problems I have with how to define BuildListeners inside
> > Buildfiles is how to mannage <ant> and <antcall> tasks. When I made
> > a recursive call using <antcall> do I create new listener instances?
> Unless you guard against it with some properties or something, this is
> what would happen in the current implementation.

Well, there is no current implementation of what I was thinking on doing
(not using a task for the declaration) ;-)

> If <antcall> only reuses the same object tree as the parent build, we
> should be able to avoid that.
Very true. But that will be only possible in ANT2, while I was thinking
more in ANT1.

I guess the problem we have is that listeners (as currently defined) are
not as much a feature of Project but of the JVM executing it. For example
when you call <ant> to another project,while a listener is active, I would
expect to receive event from the <at> subtasks. 
So they are not really a Project thing I guess they get inherited.

> > Notice that tasks similar to <sound> and <record> are fine as long
> > as one knows such composition may be instantiated multiple times.
> Why is <record> OK here?  It could overwrite an existing logfile (at
> least on file systems where Java doesn't lock files it is writing to).

Looking at <record> documentation, it really keeps track of things on its
own static table which is not Project dependent. It looks better than
I originally thought :-)

1) I would have prefer <record> to also work as a TaskContainer which
would allow for the listener to be added and removed from the project
when not needed anymore. The current code lives the recorders runnning forever.

2) I think "setName(String fname)" should be "setName(File fname)"
that would guarantee that there is no clashes when different subbuilds in 
different basedirs use the same local filename.

3) I think <record> would suffice if it where allowed to be declared
outside targets. After all <record> is just another declaration.

Jose Alberto

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

View raw message