On Thu, 14 Feb 2002, Steve Loughran <[EMAIL PROTECTED]> wrote: > From: "Magesh Umasankar" <[EMAIL PROTECTED]>
>> I am working on creating this in a more generic >> way and I don't like comments="#,-" approach very >> much... > > slick Yes. > I'd request that there is a filterreader interface that they are all > derived of, and that that if you spec a short name > 'ZapLineCommentsFilterReader' then there is no need to give the full > path. Or even shorter than that 8-) We should follow the same logic like mappers, compiler implementations or junit formatters. Provide short names for the built-in options and take everything that is not recognized as a class name. BTW, you'll probably need nested classpath elements sooner or later. > One issue: how do you pass parameters to the filters. Something like > a strip line breaks filter needs to know the char to replace it by; > the comment filter needs them too. Perhaps a <param name value> pair > is needed there. Yes, seems like the best choice in Ant 1.x design. I've been thinking about something similar for a <usercondition> for user defined conditions. Stefan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
