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 07:24:33 GMT
On Sat, 11 May 2002 15:24, Peter Donald wrote:
> On Sat, 11 May 2002 12:36, Adam Murdoch wrote:
> > > However that requires that I finish moving the "Project" logic to a
> > > task (basically moving the stuff) and for that task to read properties
> > > from context so as to know which ProjectListener to instantiate.
> >
> > Why would the project task need to know which listener to instantiate?
> > Wouldn't that still be the app's responsibility (with maybe the embeddor
> > instantiating on the app's behalf)?
> Well apps that want that ability will be able to do it via TaskListeners.
> IMHO ProjectListeners will do basically what they do now (ie write to
> streams, write to files etc). However they are just a convenience layer.
> For "real" integration into GUIs etc you would use  a TaskListener.

Using ProjectListeners isn't portable across project models.  We'd be better 
off having the general-purpose output stuff done by TaskListeners instead.

Even if they are ProjectListeners, I still don't see why the project task is 
responsible for doing the instantiation.  Or even needs to know about 

> The way I plan on doing it is figuring out common meta-info about different
> components and getting people to mark up the components with XDoclet tags.
> Then from that we can generate whatever meta-data we need to run in
> whatever container.

Component meta-data, eh?  Oh, right, you mean the hard-coded class names in 
DefaultEmbeddor :)

> > Will we be able use more of the container
> > type stuff from elsewhere too?
> Im not sure what you mean. I plan to homogenize the embeddor stuff from
> Phoenix, Myrmidon etc so that we can reuse large chunks of it.

That's exactly what I mean.  Right now, it seems that there's a bit too much 
container infrastructure code in myrmidon.  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.

> BTW a few people have been asking about your VFS layer but I am not really
> sure on its status at this stage. 

It's been on hold for a while.  I was planning to get back in to it after 
getting this antlib stuff sorted.  Even so, it's in a pretty good state, 
except that it really needs more providers (http/webdav in particular).  And 
I really need to port more tasks and data-types to it.

> It is likely however that in the future
> other people will want to use this and some of the other features we have
> in myrmidon (particularly the native execution service, and javac service).

Yep - that's been the plan all along, right?


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

View raw message