ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject RE: [PATCH] User defined types and tasks to be loaded before defa ult ones are...
Date Tue, 26 Nov 2002 22:04:42 GMT
I was talking about what I use in embed to load hooks for 
dynamic properties, task factories, etc.

I'm not sure how the selectors are plugged in - but an ant
task does have a lot of control. Taksdef is just a regular task,
and we have a lot of other meta-tasks.
Import ( and any similar stuff that modifies the build tree )
is implemented as a task. 

So far I couldn't find almost anything that can't be done by
a (maybe special) task. Probably the ProjectHelper hook - since
it happens before build.xml is read - but top-level tasks
at the beginning of build.xml can do almost anything ( even
rewrite the build tree - like import does - or replace any 
kind of tasks ).


Dominique Devienne wrote:

> I'm confused by what you just wrote!
> I have a custom selector impl. The only way to plug in to the selector
> mechanism (which I find really great by the way) is thru the extend
> selector. It's not a task. The Java class is loaded by ExtendSelector
> directly if I specify a classpath, so I cannot access any tasks/types
> loaded from <task/typedef>.
> So I can I already have my custom selector access Project and take a
> nested <path>? And how can I can that Path into my custom Buildpath data
> type, which by the way itself loads a resolver class (what I called a
> custom extension point).
> Where you talking about what will be possible after some of [embed] make
> it to Ant Core? Like I said, I'm confused... --DD
> -----Original Message-----
> From: Costin Manolache []
> Sent: Tuesday, November 26, 2002 2:24 PM
> To:
> Subject: RE: [PATCH] User defined types and tasks to be loaded before defa
> ult ones are...
>> I personally believe we need a mechanism to load and configure other
>> types of Ant extension points (Mappers, Conditions, Selectors, Filters,
>> XmlCatalog resolvers, and even custom extension points) similarly to
>> what's currently possible for tasks/types, which is good enough for now.
> I think we do have one already :-)
> Any task can call methods in Project and core and add whatever hooks it
> wants.
> For example in order to plug a particular antlib impl or a PropertyHelper
> you just have a regular task that calls the add method.
> It is easy to add "magic" - i.e. if a task implement one of the hooks
> interfaces we can add it automatically, but it's more flexible and
> clean to let the task control that ( apache2 modules follow the same
> model, there is a single "module" that can add itself to any hook ).

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

View raw message