ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <>
Subject Re: [myrmidon] TaskListener and friends
Date Sat, 20 Apr 2002 09:18:00 GMT
On Sat, 20 Apr 2002 15:56, Peter Donald wrote:
> Hiya,
> interesting questions (many of which I hadn't thought about).
> On Tue, 16 Apr 2002 22:48, Adam Murdoch wrote:

> >  Who is allowed to fire events?  Can tasks?
> > All services?  A single service?
> Well not sure. I was thinking that it is only really necessary for the
> Executor to have access to firing mechanisms. It would then call it at
> start/end of task execution and it would also binf a stream to
> System.out/err and have that stream redirect output as events.

Yep, this is better than the workspace firing them.  Would we do away with the 
'project-started', 'target-started', etc events (since they can be implied 
from the task events)?  How would we distinguish between events from the same 
task being executed in different execution frames?

How would the input stream deal with async. execution?  Same as ant1?  If so 
we probably want some way for a task to attach whatever extra threads it 
spins up.

> > * How does a listener get registered?  How does a task register a
> > listener? Or an app?  Or a service?
> No idea. Maybe another service?

Sure.  Makes scoping simpler, and would allow the event infrastructure to be 
made more general later on.

> > * Are events scoped?  That is, are they visible outside the execution
> > frame where they were fired in?  In parent frames?  Child frames? 
> > Globally? Depends on the listener?
> Not sure. Scoped listeners sound interesting. You add a listener at a
> specific ExecutionFrame and all events below that gets delivered - I like
> that. Of course we would need an escape mechanism that said add this to my
> parents frame (ie to change verbosity of a target) or top-level frame (ala
> project listeners) or whatever.

Perhaps as a separate service interface, so that we can restrict access to it.

> > * How are events typed?  Are the types extensible?  Can we fire, say,
> > 'external command started' or 'type registered' events for inter-service
> > communication?
> I was thinking they are less a communication system and just notification
> about event execution and thus the even should be final. However if we
> wanted a command bus maybe we could build another system.

True.  Forget that idea for the time being.


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

View raw message