ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: antlib descriptor
Date Tue, 19 Feb 2002 13:33:09 GMT
Steve Loughran wrote:

> Also, can you leave some space inside this DTD for adding in implementations
> of abitrary roles, even if we dont actually support such roles in Ant1.5.
> Example: conditions, ejbjar extensions, javac and jsp factories. That way we
> can tack full support for them in in the post 1.5 timeframe inside libraries
> that will also work (downgraded) on ant 1.5.

Let's agree on the concept of roles firstly then :-)

I have not implemented roles in mutant as I have always found the 
descriptions relatively complex. What are the goals of defining and 
using roles? As far as I can see this is to allow extensibility, 
primarily the ability to define new nested elements for a task without 
changing the task.  Mutant supports this capability in, IMHO, a simpler 
way, although it is perhaps less appealing syntactically.

To understand the propsals being put forth to support roles, I have 
studied Jose Alberto's sandbox proposal. Jose Alberto, could I ask that 
you do not use tabs. You may also consider using a tool like checkstyle 
to verify your Javadoc. Anyway, this is my understanding of how roles work.

Lets say we are presented with the following construction

where foo is an instance of Foo class and we are trying to create the 
nested element bar. It appears that before the standard addBar, 
createBar methods are checked, the code will attempt to use the role 
framework to create the nested element. I think myrmidon does this in 
the other order.

ProjectHelper calls IntrospectionHelper to create the nested element.

IntrospectionHelper calls Project.createInRole.

Project.createInRole calls SymbolTable.findRoles to find all Roles which 
are implemented by Foo.class. This works by iterating through all the 
roles in the system and checking if Foo implements the Role's 
corresponding interface. findRoles returns a list of the satisfying Role 

Let's say there are three roles - thing, widget, dunsel - returned.

For each of these roles, Project calls createForRole, passing the name 
of the role and the name of the nested element (bar in this case). For 
each role, it attempts to find a factory calling SymbolTable.get (I 
think this should be renamed getFactory). The factory object is used to 
create the instance. If more than one factory is found, an error is 
thrown. Lets say Foo implements Thingable. "bar" must have been 
registered as supporting the Thingable role (not that it implements 

The symbolTable object is consulted each time to get the interface 
method corresponding to the role. If only one instance is created, the 
interface method is invoked on foo with the instance.


If I understand Peter's description of roles in myrmidon (from 7th Jan 
email, I also had a quick look at the code but it wasn't clear to me), 
it is pretty similar to the above, although the role is associated with 
the interface implemented by the nested instance rather than by the 
"container" class. IOW, rather than searching for every role interface 
implemented by Foo.class, myrmidon searches for interfaces based on the 
existence of add(X x) methods. It determines the roles by looking up the 
role that corresponds to class X.

If we boil down what roles do, I see it as
1. determines the type of the instance that should be created
2. determines the method which should be called to add that instance

I took a slightly different approach to that problem in mutant. The 
syntax I use is
   <thing ant:type="bar">

So, the nested element name identifies the method to be called 
(addThing()) and the data type is given by the ant:type attribute. The 
name, "bar" is a standard Ant datatype registered with typedef, for 
example. I am using the ant namespace for the necessary metadata. I also 
use it to identify reference instances (ant:refid), I think myrmidon 
adds "-ref" to the element name.

To give an example using real Ant types.
   <fileset ant:type="zipfileset">

Mutant's approach is pretty simple and also quite explicit. The build 
file writer asks explicitly for the type they want, rather than the 
background plumbing figuring it out. The roles approach has always 
seemed a little complicated to me. I guess the downside in my approach 
is that the syntax is a little ugly.

Anyway, I'd appreciate your thoughts. If everybody thinks roles are the 
way to go, I guess I'll have to handle the complexity. Also it would 
probably be worth harmonizing on which interface we are going to 
identify with the role.


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

View raw message