> -----Original Message-----
> From: Peter Donald [mailto:[EMAIL PROTECTED]
> 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:
<javac>
<classpath location="...">
<path path="..."/>
</classpath>
</javac>
while allowing type substitution:
<javac>
<classpath type="my-path-impl" ... />
</javac>
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.
Adam
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
