On Wed, 10 Apr 2002 17:26, Adam Murdoch wrote:
> > > > Then we come across the problem - what do we call the service
> > > > providers. We could keep the name "components.*" or could go to
> > > > something like "providers.*" or go to an ant specific terminology
> > > > (for example the providers in phoenix are cllaed blocks and we put
> > > > them in the blocks.* hierarchy).
> > >
> > > Um, the service providers? Which bit are you referring to there?
> >
> > basically the objects that implement the interface.
>
> The interface being the service, I presume? So we have:
yep. Sorry I use a whole bunch of terms almost interchangably ;)
> Service == the interface through which you use the service == interfaces.*
> Service provider == an implementation of a service == components.*
yep.
> Seems like 'providers' is a better heirarchy name than 'components'. So we
> want to rename
>
> o.a.myrmidon.interfaces -> o.a.myrmidon.services
> o.a.myrmidon.components -> o.a.myrmidon.providers
I dont really mind. I like current approach but that one is also good. As
long as they are separated then I will be happy.
> > > They definitely need work. How about we axe the stuff in aspects
> > > altogether?
> >
> > Doh! Took me ages to figure out how to code em like that - ohwell. I
> > guess they really haven't provided bang for buck so yer remove them.
>
> Leave 'em there if you want.
Ill zap them until we need them. Just hate deleting code I spent ages on ;)
> > > For listeners, how about we move the interfaces and
> > > AbstractProjectListener -> o.a.myrmidon.api.listeners, and the
> > > remainder to antlibs.core.
> >
> > I don't like moving to api.listeners as I want to keep the api.* tree
> > only tied to tasks - not to the workspace, project, target and other ant
> > artefacts. If we could generalize then event infrastructure then +1
> > otherwise lets hold off for the time being.
>
> Sure. Just out of interest, what is the distinction between listeners,
> and, say, a project builder, or workspace, or anything else in interfaces.*
> ? Why are they off in their own package hierarchy?
Well I was thinking that listeners are things that end-users would want to
extend. So it is the sort of thing that task writers would want to use.
Whereas the interfaces.* hierarchy is more useful to people who want to
radically alter the way the container works
> > Anything else you want to maintain history about ?
>
> Nope.
Started to move. Aut/site is moved and seems to be working. However I believe
I broke a bunch of unit tests in main tree. Will fix tonight.
--
Cheers,
Pete
Frank Zappa observed: "It's not getting any smarter out
there.You have to come to terms with
stupidity, and make it work for you."
--
To unsubscribe, e-mail: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
|