From: <[EMAIL PROTECTED]>
> 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 ...>
<param.../>
</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 java.io.Filter 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 java.io 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="org.apache.tools.ant.filters.StripLineComments">
> > <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
>
Cheers,
Magesh
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
