ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Magesh Umasankar" <>
Subject Re: [VOTE] Promotion of FilterReaders proposal to main development tree.
Date Thu, 28 Feb 2002 03:47:24 GMT
From: <>

> I have the following comments:
> - Parametrizable/Parameter. Ant already have a clear ( and pretty good )
> set of rules for setting properties in java objects, using introspection,
> etc. There is no need to introduce this concept, using the same mechanism
> as for tasks should be enough.

I am not sure I follow:

For a given declaration like the following,

<filterreader ...>

I am making use of Ant's introspection mechanism
to add elements to antfilterreader.  However, I need
to be able to propogate those parameters to the
class that antfiltrerreader instantiates - for that
I need Parameterizable.

> - AntFilterReader - I prefer a more generic mechanism. What it does is
> 'wrap' a into an ant datatype. The same thing can
>  be better achieved in a generic way - using a TypeAdapter ( similar
> with TaskAdapter ). <antlib> proposal ( and my proposed refactoring
> of Task/Type management ) would provide this - all you have to do
> to add the filter is use a typedef ( and that'll take care of
> automatic property setting using introspection - so no need for
> Parameter ).

_When_ <antlib> makes its way in, I will
be one of the first to jump into its bandwagon...
But till then, I don't want that to suspend
progress on everything else.

> - I _love_ your aproach of extending a interface !!
> On that alone you have my +1 ( if you remove the Parametrizable
> and let the filters be simple beans, with no deps on ant -
> none is needed !).

The basic idea was to be able to be able
to plug in Ant-independant custom
filterreaders.  Maybe I didn't mention it
explicitly, but for a user to plug in
a custom filter, she doesn't need to use
_any_ of Ant's APIs.  As far as parameterizable
goes, I have explained it already.

> I'll add more comments as I read the code, but so far
> filters/ are fine ( without Parametrizable ). If you agree
> to use <antlib> or an extended <typdef>, most of what
> you added in types/ will not be needed, and you can

I will make use of it as soon as it gets
accepted into the main tree.  Fair enough?

> group ChainFilterHelper ( which is not likely to be
> used outside your package ) with the FilterReader type.

ok.  Can move it to filterreaders/util package.

> Your first example will no longer be needed, a <typedef> or
> <antlib> will be enough to elimnate the need to use the full
> class name and <param>
> >         <filterreader
> > classname="">
> >             <param type="comment" value="//"/>
> >             <param type="comment" value="REM "/>
> >             <param type="comment" value="--"/>
> >         </filterreader>

That is true.  This is available only to work around
the limitations of the _current_ Ant1 model.

> Costin


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

View raw message