ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: [myrmidon] add TaskContext.getService()
Date Sat, 26 Jan 2002 02:20:44 GMT

> -----Original Message-----
> From: Peter Donald []
> Sent: Saturday, 26 January 2002 6:59 AM
> To: Ant Developers List
> Subject: Re: [myrmidon] add TaskContext.getService()
> Also rather than making DefaultTaskContext Composable I just passed the 
> ComponentManager in via the constructor. Seemed simpler and less 
> likely to cause problems.

Ah good.  I wasn't sure if it was the 'myrmidon way' to make something like this Composable.

Any thoughts on how we might add services at runtime?  Seems like we have a few places where
service definitions will need to come from:

* A typelib that adds a new service type, may also want to specify a default implementation
to use.

* The system and user config files, may specify an implementation to use.  The implementation
would also need to be configured here.

* The build file, may explicitly specify an implementation to use.  Global, and per-task.
 Also needs to be configured.

It's probably worth doing up a ServiceManager interface, and a hierachical DefaultServiceManager
impl.  It would manage mapping between the service interface and the implementation object.
 I don't think it's worth having the ServiceManager handle more than one implementation of
a particular service.  This way, in any given context, there will be a single active implementation
of a particular service.

We're going to need a Service role, too, so we can instantiate via a TypeManager (i.e. from
typelibs).  A hierarchical role/type model like we discussed earlier would be handy here,
so we can refine the Service role into roles like JavaCompiler, JavaLauncher, CommandLauncher,
FileSystemManager etc.  In the meantime, we can bung them all into the Service role for now.
 Which means we need a Service marker interface for the time being.

Adding services in the type library is easy enough - should work right now, if we add a Service
role.  It would be a useful thing to introduce the concept of a default implementation to
TypeManager/TypeFactory, I think.  It will also come in handy for our general-purpose types,
like <path>.

For example, say we make Path a simple list-of-files interface (which is how almost everything
uses it):

public interface Path {
   String[] listFiles( TaskContext context );

Then, we add a DefaultPath implementation, which behaves the same as the <path> data
type currently does, and make it the default implementation for Path.

This would allow the configurer to support the existing style:

   <classpath location="...">
       <path path="..."/>

while allowing type substitution:

    <classpath type="my-path-impl" ... />

Specifying a service implementation in the build file is simple enough.  A task that instantiates
and configures the service object, then uses the ServiceManager to make it active in the current
context, would do the trick.

As far as system and user config files goes, a good model might be to treat these as mini-projects,
which get executed at the start of a build, to configure the root execution frame.  Whether
the launcher does this explicitly, or the embeddor/workspace does it implictly, doesn't matter
at this stage.  Then, the config files would use the above task to specify an implementation.


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

View raw message