> From: Matt Benson [mailto:[EMAIL PROTECTED] > Peter's proposition allows to define > the implementation type directly in > types/defaults.properties, then nest these directly > into the <mapper> element. In this way <mapper>s > would/could look a lot more like <condition>s and > <selector>s, especially when ref'd.<snip>. > So... does anyone have a problem with > changing the recommended usage of <mapper>s while > maintaining BC?
+1 to making <mapper>s look like other extension points in Ant (<condition>s, <selector>s, etc...). I also think that Ant might support for these extension points to be defined in the META-INF/services folder of dirs/jars, as documented in http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider It would be a simple matter to extend the JAR spec format to specify Ant-specific attributes in the comment string of the same line: .../META-INF/services/org.apache.tools.ant.types.Condition com.lgc.buildmagic.SuperDuperCondition # tag=superdupper OTOH, this kind of duplicates what's already possible to define in the Ant-specific antlib.xml, and might not play well with XML namespaces of Antlib... It does feel like defining Ant extension points that implement a given interface, or extend a given abstract class should use JDK sanctioned discovery mechanisms. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
