You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Adam Murdoch <ad...@apache.org> on 2002/05/11 03:46:19 UTC
[myrmidon] ProjectListener
Hi,
Any objections to getting rid of ProjectListener, and replacing it with
TaskListener? Or to changing TaskToProjectListenerAdapter to
TaskToBuildListenerAdapter and moving it to ant1compat?
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] ProjectListener
Posted by Peter Donald <pe...@apache.org>.
On Sat, 11 May 2002 19:21, Adam Murdoch wrote:
> 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.
I would prefer we dont - at least not now. This introduces more complexity
than we really need. Keep the components simple and assemble them in *smart*
ways rather than having smart components if you get what I mean. It may mean
a little bit of duplication as we evolve but it is far more flexible IMHO.
> > 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?
No idea yet ;) I will tell you when I figure it out ;)
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] ProjectListener
Posted by Adam Murdoch <ad...@apache.org>.
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,
necessarily.
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?
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] ProjectListener
Posted by Peter Donald <pe...@apache.org>.
On Sat, 11 May 2002 17:24, Adam Murdoch wrote:
> > 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.
yep.
> 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? ie How would you do a generic outputter when you are dealing with a
gump/vindico project or a maven project compared to regular ant project. We
could make ProjectListeners implement TaskListener and access them via that
(it was previously this way). I just though this was a bit hack so I
separated it out.
> 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.
> > > 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.
agreed.
> 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.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] ProjectListener
Posted by Adam Murdoch <ad...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] ProjectListener
Posted by Peter Donald <pe...@apache.org>.
On Sat, 11 May 2002 12:36, Adam Murdoch wrote:
> I can live with it moving to framework. How about in the meantime, we just
> add Workspace.addListener( TaskListener ) ? Then I can get the tests
> working again, without waiting for this to get sorted out.
no problem.
> > 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.
> Framework is currently in the 'common' classloader (from
> http://jakarta.apache.org/ant/myrmidon/classloader.html), although it
> should be in the 'shared' classloader (which we don't have atm). So it
> will be visible to the container. For now.
okay then move it away ;)
> > Currently I am working on cleaning up some Avalon stuff and I am going to
> > make a proposal so that the services we implement can be shared between
> > Myrmidon, Phoenix, Merlin, Fortress, ECM etc. Hopefully that means we can
> > rely on a bunch of ex-Cocoon stuff to do some of resource/xml/xslt/other
> > magic.
>
> Excellent - what's the plan?
Mainly to get other people to maintain the services/container that is not core
part of myrmidon :)
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.
> 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.
However I guess you mean what services can we nab from other places? I am not
sure there is many besides the generic ones from Cocoon. The main reason is
that the services often come from very server orientated apps (CORBA, FTP,
Mail, Jabber, EJB, LDAP) or vertical markets - none of which is really useful
to us ;)
There are some "generic" services that I know of which may be useful (ie
Script/BSFService) but because we have such specific needs I am not sure we
can use them. Anyways I will poke a few people to see what I can come up
with.
BTW a few people have been asking about your VFS layer but I am not really
sure on its status at this stage. 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).
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] ProjectListener
Posted by Adam Murdoch <ad...@apache.org>.
On Sat, 11 May 2002 11:55, Peter Donald wrote:
> On Sat, 11 May 2002 11:46, Adam Murdoch wrote:
> > Any objections to getting rid of ProjectListener, and replacing it with
> > TaskListener?
>
> I think we should probably keep it around for the time being. Mainly as it
> easier to write a ProjectListener than it is to write a TaskListener. I was
> going to move it from api to framework (and concrete implementations to an
> antlib).
I can live with it moving to framework. How about in the meantime, we just
add Workspace.addListener( TaskListener ) ? Then I can get the tests working
again, without waiting for this to get sorted out.
> 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)?
> Currently ProjectListener is instantiated in the container which means it
> would not be possible to "see" the ProjectListener if it was moved to
> framework right away (due to not being able to see Framework ClassLoader
> ... unless thats changed recently).
Framework is currently in the 'common' classloader (from
http://jakarta.apache.org/ant/myrmidon/classloader.html), although it should
be in the 'shared' classloader (which we don't have atm). So it will be
visible to the container. For now.
> Currently I am working on cleaning up some Avalon stuff and I am going to
> make a proposal so that the services we implement can be shared between
> Myrmidon, Phoenix, Merlin, Fortress, ECM etc. Hopefully that means we can
> rely on a bunch of ex-Cocoon stuff to do some of resource/xml/xslt/other
> magic.
Excellent - what's the plan? Will we be able use more of the container type
stuff from elsewhere too?
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] ProjectListener
Posted by Peter Donald <pe...@apache.org>.
On Sat, 11 May 2002 11:46, Adam Murdoch wrote:
> Any objections to getting rid of ProjectListener, and replacing it with
> TaskListener?
I think we should probably keep it around for the time being. Mainly as it
easier to write a ProjectListener than it is to write a TaskListener. I was
going to move it from api to framework (and concrete implementations to an
antlib).
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.
Currently ProjectListener is instantiated in the container which means it
would not be possible to "see" the ProjectListener if it was moved to
framework right away (due to not being able to see Framework ClassLoader ...
unless thats changed recently).
Anyways I am slowly working on it and have tried three different ways of doing
ProjectTask. None look any good so I will try again on Monday.
Currently I am working on cleaning up some Avalon stuff and I am going to make
a proposal so that the services we implement can be shared between Myrmidon,
Phoenix, Merlin, Fortress, ECM etc. Hopefully that means we can rely on a
bunch of ex-Cocoon stuff to do some of resource/xml/xslt/other magic.
> TaskToBuildListenerAdapter and moving it to ant1compat?
Thats a kool idea in itself.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>