DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17199>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17199 patch to allow custom conditions (+ filters..) ------- Additional Comments From [EMAIL PROTECTED] 2003-02-21 18:14 ------- Thanks for this thorough patch, of a very valuable (to me) addition. I have two comments though: 1) I'm not really fond of 'miss-using' <typedef> to declare you're custom condition/filter/mapper/selector. I think you should either add new <conditiondef> / <selectordef> / etc... declarations for each type of extension, and/or directly declare these extension at the point of use, like in: <target name="custom-condition"> <path id="testclasses" path="..." /> <typedef name="custom_condition" classname="org.apache.tools.ant.taskdefs.condition.CustomCondition" classpathref="testclasses" /> <condition property="custom-condition-true"> <custom name="custom_condition" classname="com.acme.CustomCondition" classpathref="testclasses"> <custom_condition testvalue="true"/> <custom /> </condition> <echo>${custom-condition-true}</echo> </target> Perhaps instead of having one <somethingdef> for various types of classes/interfaces, we could have a single <extensiondef> new task taking an additional 'implements' attribute? <extensiondef name="mycondition" implements="org.apache.tools.ant.taskdefs.condition.Condition" classname="com.acme.MyCondition" classpathref="testclasses" /> 2) Changing the API of <mapper>... Always better to keep the current API, and add a new way to declare a custom mapper. But beside this nit picking, this is a great addition, which was something that had been bothering me with Ant. I hope Stefan, Conor, and others will look at it, and comment on it, so it can make it to 1.6! Thanks, --DD
