ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: antlib descriptor
Date Wed, 20 Feb 2002 08:31:56 GMT
Jose Alberto Fernandez wrote:

> From: "Conor MacNeill" <>
> To jump ahead, I really dislike Mutant extensibility approach. 

Fair enough.

> I wouldn't
> mind it as a way to resolve ambiguities, but to be the only notation 
> for doing it, that I really dislike. We are talking not only about exotic things like
> <ejbjar> but also basic things like <condition>, <mappers>, etc.
> Needing to use Mutant's notation all over the place, defeates the hole
> purpose.

It does not need to be used all over the place. BTW, what in your view 
is the whole purpose?

> I will do that when things are a little more stable, with so many ideas comming from
> guys, I am still changing things around. 

I think it would help more people understand what is going on if you 
were to format and document it. I know what you mean about making 
changes but that is even more reason to keep Javadocs up to date.

> This is a fair description. Notice that the reason it is the way it is, is to
> make it compatible with ANT1 and in particular the way in which ANT1
> defines containers of tasks (i.e., interface TaskContainer). This is why
> the role is defined by the interface implemented by the role.

I think basing it on the container interface is pretty ugly. It means 
that for every nested element that a task supports, which is to allow 
polymorphic elements, the task will need to implement a separate interface

How long before we are implementing such a large number of interfaces

myTask implements Filesettable, Mappable, Conditionable, Thingable, ...

You say you don't think there will be many roles defined. I disagree. 
Once typedefs become generally useful, i.e . once polymorphism becomes 
workable, people will be defining many roles. Also for this to be 
workable, the Task writer has to consider each nested element that he 
wishes to support polymorhpic behaviour. It cannot be added in after the 
task has been written (i.e. will need a recompile/new release). For 
example, say someone wants to change the Javadoc task to pass in a new 
type of header (hypothetical example) from




If the author of Javadoc did not create and implement a Headable 
interface, you can't do anything.

> Additionally in myrmidom, if I remember correctly, there is a requirement that
> the methods for roles, must have interfaces as the type of the arguments,
> but since ANT1 uses classes instead of interfaces to define almost everything
> this approach would have problems in ANT1.

I'm not sure this is true but I'll let Pete/Adam comment.

> As  said before, I really dislike the syntax in Mutant in particular because
> with a syntax like that there is no need for the "ant:type" attribute,
> one could get the same result with similar notation using the current ANT1.

No, you would need to make changes in IntrospectionHelper to separate 
creation from addition.

> Bt for some reason people dislike it (that is why we keep on having things
> like <ejbjar>, <condition> etc.

I'm not sure to what you are referring when you say people disklike 
"it". When has this sort of facility been implemented

> If your syntax where instead of the form:
>    <foo>
>       <bar ant:role="thing" >
> Then at least I could see this syntax as a way to disambiguate things. But I would
> still like to make such attribute optional.

It is optional, of course, only being required where you want to 
override the type normally expected by the task. So if I have

A fileset will be created automatically and used for the nested element.

> Yes ugly, too ugly, uglier that a box of chocolates :-)

Is that a Gump reference? :-)

> Whatever we decide, we need to take into account the restriction of not breaking
> ANT1 ad the way it does things. In perticular this means that mutant and myrmidom
> aproaches will not work because the syntax is incompatible with the tasks 
> already inexistance. That does not mean that my should be taken as is, I am open for

Having thought about this a bit more I think, besides the hokiness of 
having to implement a separate interface for every extensible nested 
element I want to support, there are problems when a task supports two 
nested elements with the same underlying type.

For example, consider a task which takes two filesets
   <fromFS .../>
   <toFS .../>

It has methods like this
addFromFS(Fileset from);
addToFS(Fileset to);

I cannot have both of these being extensible. I couldn't use a 
classfileset for both since only one can be mapped to the interface 
method of the Filesettable role. I'm not sure myrmidon supports this 
scenario, if I read Peter's explanation literally, since it is searching 
for add(X x). Of course if it is were to search for
addXXX(X x)
methods, it wouldn't be a problem, I guess.

Again have a look at the javadoc task and the addHeader, addBottom, 
addDoctitle methods. How could these be made extensible.

It is of course simple in mutant, even if you find it ugly.

If we have to have roles, I think they must be based on the class 
supported by the nested element rather than the container.


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

View raw message