ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject RE: multi-result <mapper>s
Date Mon, 09 Feb 2004 23:36:46 GMT
> From: Matt Benson []
> Peter's proposition allows to define
> the implementation type directly in
> types/, 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
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:

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:
For additional commands, e-mail:

View raw message