It should be possible to use the same type discovery mechanism we now use for Tasks and referencable elements to discover filterreader classes in a given assembly. Or somthing similar using attributes.
Ian
Gert Driesen wrote:
Mitch,
The filterset implementation currently does not allow for other types of filters to be set, that's what the filterchain support was intended for.
I'm not sure on how to proceed with this, we could rework the filterset implementation (which, right now, is more or less a port of the Ant filterset) to allow custom filtersets but this would actually mean that the filterset implementation is moving toward a filterchain implementation (which is not bad ofcourse) ....
It would change the build layout of the filtersets considerately ofcourse ... It would also mean that we would not be able to use the Element initialization code that we use for all other types, as this would mean that we'd need have a separate property for each possible type of filterreader in the filterchain, and this would prevent further extensibility by third parties ...
Ant support two notations for built-in filterreaders :
<filterchain> <filterreader classname="org.apache.tools.ant.filters.ReplaceTokens"> <param type="token" name="DATE" value="${TODAY}"/> </filterreader> </filterchain>
and
<filterchain> <replacetokens> <token key="DATE" value="${TODAY}"/> </replacetokens> </filterchain>
For third party filterreaders only the first notation is supported, ofcourse.
If we decide to go for the filterchain implementation instead of the fitlerset, I might some need help as I don't think I'll be having much time (at least not enough, I think) in the next week or weeks ...
I certainly would like to avoid having to support both filtersets and filterchains, like Ant is forced to do because of backward compatibility, so we should decide on this as soon as possible ...
I'd definitely prefer going for the filterchain support, even if that means that I've wasted my effort on the filterset implementation, but as I said, I could use a hand ...
Gert
----- Original Message ----- From: "Mitch Denny" <[EMAIL PROTECTED]> To: "Gert Driesen" <[EMAIL PROTECTED]>; "Ian MacLean" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, October 07, 2003 11:58 AM Subject: RE: [nant-dev] [Fwd: Ready to tackle next release]
Cool, so should I bother with the replace task? One of the tasks modes is NAnt and Regex (as well as simple text substitution). The begin and end token attributes wouldn't make sense in that case and it would (possibly) be better to do something like:
<filtersets> <filterset> <propertyfilter> <propertyset> <exclude property="nant.project.basedir" /> </propertyset> </propertyfilter> </filterset> </filtersets>
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
