Expressing BuildListeners (was Re: [Ant2] Tasks as siblings of )

[Jose Alberto Fernandez <j_...@yahoo.com>]

From: "Stefan Bodewig" <bo...@apache.org>
> On Wed, 31 Oct 2001, Steve Loughran <st...@iseran.com> wrote:
> 
> > Could/should this construct also include definitions of things like
> > buildlisteners?
> 
> This can be done from inside a task (<sound> and <record> are
> examples), but things like attaching aspect handlers will be tied
> closer to Ant's core than that.  One could do this using tasks as
> well, but these tasks will be exposed to internal changes in Ant's
> core a lot more than "normal" tasks.
> 

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?
This is certaintly not the behaviour I want in most situations (e.g., E-mail).

To that extend, it seems like listeners in Buildfiles need to be treated 
in a special way. Notice that tasks similar to <sound> and <record> are fine
as long as one knows such composition may be instantiated multiple
times. 

Jose Alberto



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Expressing BuildListeners (was Re: [Ant2] Tasks as siblings of )

[Jose Alberto Fernandez <j_...@yahoo.com>]

From: "Stefan Bodewig" <bo...@apache.org>

> On Mon, 5 Nov 2001, Jose Alberto Fernandez <j_...@yahoo.com>
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Expressing BuildListeners (was Re: [Ant2] Tasks as siblings of )

[Stefan Bodewig <bo...@apache.org>]

On Mon, 5 Nov 2001, Jose Alberto Fernandez <j_...@yahoo.com>
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.

If <antcall> only reuses the same object tree as the parent build, we
should be able to avoid that.

> 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).

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>