ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: [myrmidon] moving to new module
Date Tue, 09 Apr 2002 02:07:35 GMT
On Tue, 9 Apr 2002 10:57, Adam Murdoch wrote:
> > > > cmyrmidon.components.foo.AbstractFoo
> > > > cmyrmidon.components.foo.DefaultFoo
> > > > cmyrmidon.components.foo.SpecialFoo
> > > >
> > > > Does that work for you?
> > >
> > > Not quite - we sometimes need to use the abstract impl in more than one
> > > component package.
> >
> > Can you give me an example - I am coming up empty when I try to think of
> > one.
>
> One example would be specialised implementations of things that aren't
> components (or are tiny components), things like PropertyStore,
> PropertyResolver,

maybe. However they don't constitute interface between components and thus 
why I would be reluctent to move them 

> TaskContext, ExecutionFrame and so on.  

for these I don't think they should be accessible outside their package as 
such. They are tied directly to their execution model and in reality should 
just delegate to the "real" components. However if there is a need for it 
then I suppose we could chuck something like

AbstractExecutionFrame in interfaces.* 

But thats only because ExecutionFrame is part of interface between components.

> Another example would be things which we might have a couple of standard
> impls for a component, but which we want to keep in separate packages.
> ProjectBuilder is a good example - we have a couple of ProjectBuilder
> impls, which all extend DefaultProjectBuilder.  They're all in
> components.builder right now, but shouldn't be (ConvertingProjectBuilder
> and
> TransformingProjectBuilder might be better off with the ant1compat stuff,
> for example).

okay thats a good use case. However whats to stop that use case being 
staisfied by having the experimental librarys depend on the container jar?

> This is eventually going to be true of other components too - we're going
> to have a bunch of Configurers, Executors, ExtensionManagers etc, which
> will need to be scattered over the hierarchy (e.g. experimental, or
> homespun impls).
>
> The solution for the time being might just be to move shareable stuff to
> the interfaces hierarchy.

I would be opposed to that at the moment unless the shared stuff is part of 
communication layer between components.

-- 
Cheers,

Pete

---------------------------------------------------
"Marriage, Friends, Religon -- these are the demons 
you must slay in order to suceed in business.." 
                 -- Mr. Burns, The Simpsons 
---------------------------------------------------

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message