ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <DDevie...@lgc.com>
Subject RE: multi-result <mapper>s
Date Mon, 09 Feb 2004 23:36:46 GMT
> From: Matt Benson [mailto:gudnabrsam@yahoo.com]
> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message