ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 17199] - patch to allow custom conditions (+ filters..)
Date Fri, 21 Feb 2003 18:14:03 GMT
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 ddevienne@lgc.com  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

Mime
View raw message