ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: [WIP]Selectors
Date Mon, 04 Mar 2002 19:06:10 GMT
At 01:31 PM 3/4/2002 -0500, Magesh Umasankar wrote:
>Adam, I think, is referring to the FilterReader
>codebase.  FilterReader used to have a generic
>interface alone - but after the discussion we
>had with cullers where you were of the opinion
>that Ant cullers need not be limited to the same
>syntax as user defined ones, I refactored
>FilterReader to allow 'smart' syntax for Ant
>recognized filters while user defined ones
>will have to put up with the 'generic' syntax.
>However, all filters can be defined using the
>'generic' syntax as well - just like the example
>you gave for filenameselector.  User can define
>nested <param> elements to pass parameters
>to the filterreader (or selector).

Ahh, excellent idea. Much cleaner and more sensible.

Apologies for having missed the discussion on that. I saw that it was going 
on, but I skipped over it due to a lack of time recently (and I've never 
used FilterReaders). I'll go back and reread the threads now.

I'll also go over the proposal code and see what I can do to make them more 

>Naming the class attribute (of selectordef) as
>classname is an informal standard that is followed.

Sounds sensible. I'll change it.

After a quick glance over your code, it looks like you don't have a 
<filterdef> but instead define the classname as an attribute of the filter 
itself. This seems sensible to me. As a matter of fact, I found 
<selectordef> a bit of a pain to use because you couldn't refer to it in 
the same <extendselect> that you defined it. I think I should drop 
<selectordef> altogether unless there are objections. Just say, as 
<filterreader> does, that classname is a required attribute.

>You would also need a <classpath> element for
><selectordef> so that user can specify location
>of selector class which is not necessarily in
>the classpath when Ant was launched.

Good point.

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

View raw message