ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <>
Subject Re: [myrmidon] ProjectListener
Date Sat, 11 May 2002 09:21:49 GMT
On Sat, 11 May 2002 17:48, Peter Donald wrote:
> On Sat, 11 May 2002 17:24, Adam Murdoch wrote:
> > We'd be
> > better off having the general-purpose output stuff done by TaskListeners
> > instead.
> But how do you a general purpose output without a specific Project model in
> mind?

We will need something general purpose, something that uses the task path 
somehow.  Maybe like the IndentedLogger idea.  Or that simply prefixes 
everything with the task name.  Whatever.  It wouldn't be the default, 

Which makes me wonder whether we should have a default listener for each type 
of project.  Which suggests that the project task probably *should* be 
involved in creating the listener.  Or maybe the ProjectBuilder is a better 
place - bundle up all the per-project-type knowledge there (there's bound to 
be other stuff that needs to be customised).

> > Even if they are ProjectListeners, I still don't see why the project task
> > is responsible for doing the instantiation.
> Probably. I just didn't want to have the container having access to the
> framework ClassLoader.

It doesn't really need to.  The listener gets instantiated via the TypeManager 
(after all the core antlibs + framework have been registered) so the 
container doesn't need to get at the framework classloader to instantiate.  
The listener Object, once instantiated, could be run through the converter to 
wrap it in a TaskToProjectListenerAdapter.  Then the container and the 
frontends don't need to know anything about ProjectListener.  We could use 
the same approach to allow ant 1 BuildListeners to be used as well, which 
would be kinda cool.

In fact, it might be useful to get the DefaultTypeManager to use the converter 
on stuff that not castable to the expected class.  Support for an ant 1 style 
TaskAdaptor would fall out of that quite nicely.

> > We don't need to do
> > anything particularly special (except for service scoping, maybe), so
> > ideally we would be able to just use something from, say, avalon, rather
> > than writing our own container.  But all we're using atm is
> > DefaultServiceManager, as a glorified hashmap.  So it would be an
> > excellent thing to be able to use more avalon container stuff.  Stuff
> > that would be out of scope to do in the myrmidon tree - like, say,
> > meta-info driven assembly, or dependency aware lifecycle management - but
> > that we could happily use.
> yep. Thats what I am hoping to glom together from what is already sitting
> in the various avalon products. If we can't get somethign that is 100% what
> we want we should be able to get 90% from generic container and then have
> minor customization inside myrmidon.

Yay.  What do we need to do on the myrmidon side of things?


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

View raw message