ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: IntrospectionHelper request
Date Thu, 10 Jan 2002 10:56:58 GMT
On Thu, 10 Jan 2002 18:22, Jose Alberto Fernandez wrote:
> 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. 

precisely. It is the "escape and do whatever you feel like" bit so that 
people can do whatever they feel like doing and still run it inside ant with 
out messing up the container for other tasks. 

In many ways this is bad but because of the somewhat higher barrier of entry 
it is expected that it will very rarily be used except when most needed. 

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

I await your fleshed out proposal. I haven't found anything that is both easy 
and as flexible as the described approach.

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

Essentially add() fails because you can not have two adds in the same 
element. The whole question of order is one aspect of this - but even if you 
work this out then there is still a greater problem.

Take the following


Now lets assume it has two adds. The first run we we look up Role1 for "a" 
and it is found and so we add the reult instance to adder 1. We look up "b" 
in Role1 but it is not found, we do find it in ROle2 and thus we add the 
instance to adder 2.

Now some outsider comes along and registers a new type of Role1 named "b" 
(which is easy to do by just dropping librarys in right place). Now when user 
reruns tasks both "a" and "b" will be added to adder1.

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

well you are in the minority - most of the proposals have that idea and it 
was voted on ages ago IIRC :)

> 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"
>              proxy="org.apache.ant.TaskModel"/>
> 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).

Im not sure what the advantage of this. How is it any different to 

<role name="task" interface="org.apache.ant.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.

In myrmidon the Configuration is the TaskModel 

> Hope I am not completely off mark,

Not sure I follow. 



| Every rule has an exception,   |
| except the rule of exceptions. |

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

View raw message