ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [myrmidon] add TaskContext.getService()
Date Sat, 26 Jan 2002 03:00:36 GMT
On Sat, 26 Jan 2002 13:20, Adam Murdoch wrote:
> > -----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:

I was just thought experimenting with something like this at the moment. My 
experimentation made the assumptions;

* services are runtime or workspace wide
* services may or may not need to be "configured" either with workspace or 
deployment contextualization info
* multiple "falvours" of a service are not needed in the same workspace (ie 
no need to have two different VFSs or ExecManagers or whatever)

My thinking basically went along the following lines. We add a descriptor to 
jars at META-INF/ant-services.xml and looks something like

  <service role="org.apache.ant.VFS" factory="org.apache.ant.VFSFactory"/>
  <service role="org.apache.ant.ExecManager" 

or maybe

  <service role="org.apache.ant.VFS" factory="org.apache.ant.VFSFactory"/>
  <service role="org.apache.ant.ExecManager" 
      <some-config-param attribute="2"/>
       <text>Some textual data...</text>

So the Factorys would be instance of a certain interface, namely

public interface ServiceFactory
  Object createService() throws ServiceException;

The reason for this extra level of indirection (ie instantiating a factory 
rather than service directly) is because then it becomes possible for the 
services not to be heavily integrated into the ant (or avalon) runtimes. They 
only have to implement the service interface. So we can make the factory 
configurable/contextualizable or configure it via ants auotmapping features 
but the underlying service does not need be aware of this. The main reason is 
because I know there is at least one person who would love to use some of the 
ant services outside ant ;)

I am actually thiefing this design from someone else (Paulo Gasper) who saids 
he apparently stole this design from myrmidon. Wierd eh. 

So a basic ServiceFactory would end up looking like

public class ExecManagerServiceFactory
  implements ServiceFactory
  public Object createService() throws ServiceException
    final File antDir = getAntDir();
    return new DefaultExecManager( antDir );

  private File getAntDir()
    ... get dir from system property like in Execute2 class ...

Anyways I may upload a cutdown version to see what you think ?

> * 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.

Im not sure - hadn't really thought about it. Could you give me some examples 
of why you would want to change any service - I could see the need for adding 
new services but just not so sure about changing.

> 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.

ServiceManager == ComponentManager

So if we go this route we may aswell use ComponentManager directly :)

> 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.

Some of them (ie CommandLauncher) have too rigid a selection logic for it 
useful to abstract it but things like JavaCompiler and EJBPacker would be 
definite candidates for types being stored in the TypeManager. (However I 
would still like to think that these types are accessed by a Service rather 
than the task directly accessing them. Does that make sense ? ;)

> 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>.

I tend to think of services as different from types. Services persist over 
the length of the ant "execution" or at least the "workspace execution" or 
whatever term we were using for this. Types are created by tasks while 
serviuces never can be etc.

> 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.

Thats a good idea ... or at least one that is worth experimenting with. I was 
going to make them automagically loaded (much like roles are) but it could be 
useful to view them this way. JFYI this is the same model that the AntFarm 
proposal used :)



Duct tape is like the force.  It has a light side, and a dark side, and
it binds the universe together ...
                -- Carl Zwanzig

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

View raw message