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 listeners. > 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? -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
