ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject RE: Extending Ant [was RE: Comparing files in subdirectories]
Date Tue, 29 Oct 2002 22:17:02 GMT
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().
> 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).

A very simple solution:
1. define the hook interface AddSelectorHook ( we can call it 'extension 
point' :-)
2. create a helper class that will act as registry and invoker for the chain
3. Have a 'special' task that will register itself or discover/load and 
register other hook implementations when loaded
4. in build.xml you'll just load this special task ( and now it's possible
to do it at top level )

All you need to do is find the right place to insert the hook, and maybe
make it flexible. It is (IMO) quite easy to replace almost anything
in IntrospectionUtils with hook chains.

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

RC/UE is just the internal representation of the build.xml file. 
They also have the logic to create the real tasks.

Most hooks will probably go into RC/UE and ProjectHelperImpl. 
( in embed I moved most of the introspection logic out of ProjectHelper and 
into RC/UE, but there are other possible aproaches )

> 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. Maybe
> there are things from the framework that could be leveraged to not have to
> recode everything, but I haven't looked. Having played with
> DynamicConfigurator though, I do think it would work. Now that may not be
> an acceptable solution for all committers ;-)

If it can work with the current DynamicConfigurator - it doesn't have to 
be accepted, it'll be just a custom task ( until it is stable and accepted). 

If it requires some extra hooks or small changes - I don't see any good 
reason someone would opose it. 

Bigger changes may need to be split into more swallowable chunks ( IMHO ).


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

View raw message