ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject RE: Extending Ant [was RE: Comparing files in subdirectories]
Date Tue, 29 Oct 2002 20:45:44 GMT
At 05:28 PM 10/28/2002 -0600, Dominique Devienne wrote:

>Now to come to the meat of the issue... is it possible to be able to extend
>the core selectors with 'Bean-selectors' without modifying the Ant code???
>You say it's not possible, because one has to add a addXYZ() method to the
>selector containers. But as you point out, one can have a single entry point
>(a hook as Costin says) using a addBeanSelector() method, and the
>BeanSelector has to do the magic of configuring itself using the
>Bean-pattern. This is very similar to your addCustom().

Yes, there would be no reason you couldn't add a <selectordef>, for 
example. But then you have to consider <conditiondef>, and <filterdef>, and 
<javacdef>, and <jspcdef>, and...

>The tough part is the creation/loading and configuration of the
>Bean-selector, or more precisely the actual class the BeanSelectorWrapper
>would delegate to (or configure, and forward isSelected() to).

Actually, that isn't the tough part. You could easily add a generic 
extension mechanism to IntrospectionHelper to associate a tag to a class. 
The problem is that this isn't sufficient. You also need the context where 
the tag can be used. Hence <taskdef>, which can only be used in a context 
where tasks are allowed.

>I think the 'good' solution would be for the framework to do that
>automagically! I have no clue how to do that, and do not understand a thing
>to RuntimeConfigurable/UnknownElement.

Myrmidon has a nice way of dealing with this through Roles. You'd have a 
"selector" role, for example. If you haven't already, take a look at The challenge is getting 
this or something similar into Ant.

>The stop gap solution would be for the BeanSelectorWrapper to implement
>Erik's DynamicConfigurator. The problem I see with this approach is that
>it's not automated, and one must do the introspection manually.

Ok, I can see the benefit to this. It is better to be specific with tags 
and attributes than to pass them in as name value pairs. Also, using 
DynamicConfigurator would allow you to have child elements (which may 
themselves implement DynamicConfigurator), something that the <param> tags 
don't really allow.

The cost is in added complexity for the user trying to figure out how to 
write their own selectors. Do the benefits outweigh the costs? I think so, 
but others may disagree.

To do this, I would suggest adding DynamicConfigurator checking to the code 
in which is the class underlying <custom>, rather than 
creating a new selector. This code already collects the parameters in a 
Vector and, if the custom selector implements the ExtendFileSelector marker 
interface, sets the parameters. It could also check to see if the selector 
implements DynamicConfigurator and do the right thing if so.

The only complicating factor is the timing of the initialization. Right 
now, the user's custom class is instantiated at execute time. Doing so 
guarantees that the "classname" and "classpath" (or "classpathref") 
attributes have both been set. I believe that if you use 
DynamicConfigurator, child elements are created at binding time, and depth 
first. I'm not sure how to deal with that and still guarantee the class can 
be loaded correctly, though I admit I haven't spent any time thinking about 
it. Perhaps you (or someone else reading this) can see a way.

>  Maybe there
>are things from the framework that could be leveraged to not have to recode
>everything, but I haven't looked.

You mean something that would provide IntrospectionHelper-like abilities 
inside setDynamicAttribute() and createDynamicElement() so that it 
automatically called the right methods on the newly-loaded class? That 
sounds interesting. Erik?

>The big advantage I see for the writer of the custom bean-selector (or
>custom bean-filter-reader) is ease of implementation.

Really? It seems to be mostly syntactic sugar in the build file to me, 
apart from the usecase where you want a tree of parameters rather than a 
flat list of name-value pairs. The setParameters() call does the same work 
as setDynamicAttribute() would.

Having said that, there is nothing wrong with a little sugar in moderation. 
Personally, I have no objection to the <custom> selector being extended 
this way, provided that you can overcome the initialization timing issues I 
mentioned above.

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

View raw message