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 ). Costin 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 [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 26, 2002 2:24 PM > To: [EMAIL PROTECTED] > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
