ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: antlib descriptor
Date Thu, 21 Feb 2002 13:41:55 GMT
Peter Donald wrote:

> On Wed, 20 Feb 2002 19:31, Conor MacNeill wrote:
>>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
> Why do you think it is "hokey"?

If I have a method

addFileset(Fileset f)

that should be enough to allow it to be configured with a Fileset or any 
subclass of fileset. It should work whether Fileset is a class or an 
interface. I really don't think I should have to implement an interface 
for each different addXXX method my task supports. That's "hokey" :-)

Not only that, if I don't think ahead, the task will not support 
extensibility for any elements for which I do not create and implement 
an appropriate interface. Thats just bad.

>>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. 
> Im not sure why you couldn't just have something like
> public void add(Fileset fs)
> {
>   if( null == from ) from = fs;
>   else if( null == to ) to = fs;
>   else throw new Exception("Too many FileSets!" );
> }

Well that would introduce ordering semantics into the nested elements 
where today the order of nested elements is unimportant. Further, most 
addXXX methods can accept multiple instances and accumulate these. This 
would no longer be possible.

The problem with role based extensibility is that you are trying to 
determine two independent things from one name. They are the method to 
call (addfromFS or addToFS) and the actual type of the instance to be 
passed to the method. With only one piece of info you need to 
artificially limit the choices.

> In either case I don't think it is simple for the userto have multiple 
> extensible elements within the same element. 

If <ejbjar> were to be implemented today it would not be a matching 
task. It would take two filesets, one the set of deployment descriptors 
to be processed and the other the support files to be included in the 
jar.  In a particular use, I might want one to be a zipfileset to read 
the descriptors from a Zip and the other to be a classfileset to bring 
all the necessary support classes into the jar based on some root classes.

> How would they tell when an 
> instance of one extensible is meant to be used and not an instance of the 
> other extensible type? Especailly troubliung given that the same name may 
> exist in each role but represent different classes.

Yes this is the problem with roles in this context. In mutant the user 
provides two pieces of info - one determines the method - this is the 
nested element name - and the other is the type of the instance to be 
passed to the method - this is supplied by the ant:type attribute.

    <fromFS ant:type="zipfileset" dir="htdocs/manual" 
    <toFS ant:type="classfileset" dir="build/classes">
       <root classname=""/>

that is simple.

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

Well at least this would remove some of the hokiness.


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

View raw message