ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: IntrospectionHelper request
Date Thu, 10 Jan 2002 07:22:04 GMT
From: "Peter Donald" <>

> On Wed, 9 Jan 2002 19:40, Jose Alberto Fernandez wrote:
> > In any case, when I write a Task that can have elements that are tasks
> > (TaskContainer) or one that can have mappers, there should be no difference
> > from the task writer point of view on how to write its set/add methods. Of
> > course it may be that for a TaskContainer the argument is not ot type Task,
> > but some other thing like a TaskModel that you mention and I am not sure I
> > understand. But the point is that whtever it is, it should be based on the
> > same discovery mechanism that you describe for the other <roles>: "based on
> > the "add" method signature, reverse map to a role and then search on the
> > role's registry for an entry for the corresponding element".
> Well what I am saying there is essentially two ways to get extensibility. 
> 1. The first way is to get passed the TaskModel and interpret it yourself 
> (probably using the services from the container). 

The problem I have with this is that it allows a Task to violate all and any rules.
I think the container (via an enhanced Introspection) needs to be the one in control here.
By enhanced I mean that the work is not only based on Class introspection, but
the Task is allowed to say what is willing to accept (what we have been talking about
DynamicTask providing their own introspector).

> 2. The second way is via the normal reflection process where an element is 
> allowed to have a generic
> void add( SomeInterface myInstance );
> which can be used to add arbitrary subclasses of the interface 
> "SomeInterface". 
> (1) is needed because (2) does not allow enough flexability and there is no 
> reliable way to have multiple add( MyInterface ) methods in an element. If 
> you can think of a way to get rid of (1) then I am all ears but I think you 
> would be hard press to.

My point above should solve the "flexibility" problem. I would like you to explain 
why you think add(MyInterface) is not reliable. If it isn't then we have a more
fundamental problem here because if it is unreliable for Tasks then it is unreliable
for the other roles also.

> In any case TaskContainers need to be treated differently as no task can ever 
> get access to another Task instance - they only operate on the TaskModel. 
> (They pass the TaskModel to the container which executes the Task).

I really do not think special treatment is necessary. Or in other words whatever
special thing you need to do for Tasks, may need to be done for some other
<role> that we come-up with in the future. So I would say the solution is to
generalize instead of specialcase it. So here is my generalization (based on Adam's
excelent explanations).

The way I see it, what is required is to be able to interpose an extra indirection
between the interface of a <role> and the type of the parameter. In the case of
Task, this is TaskModel. So in the taskdesc.xml we are looking at things as
following these definitions:

    <role name="task" interface="org.apache.ant.Task" />

    <task name="echo" class="org.apache.ant.taskdefs.Echo" />

With this declarations, we would have to hand the Task instance directly to the including
task because of the way introspection works. Instead what you want to say is that there 
is an additional intermediary here:

    <role name="task" interface="org.apache.ant.Task" 

So now, for a method of the form add(org.apache.ant.TaskModel), we would know is
role "task", we would create an instance of the Task, and use it to construct a TaskModel
which will keep the model information and then call add(taskModel).

Now TaskModel needs to be loaded with the XML model, so it can configure its task
at the right time, but that can be accomplish by generic behaviour on the introspector
and not by something special to TaskModels. That means that other roles or proxies
can do the same. 

Hope I am not completely off mark,

Jose Alberto

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

View raw message