I agree with Stefan. I much prefer to have AntLib *specified*, as in a specification of the contract an AntLib must fullfil to be usable but Ant, than working on the tools themselves to package an AntLib (XDoclet or whatever else), or even an auto-download feature (I've looked at Ruper, and I'm not fond of this implementation, although the principle at play is useful, as demonstrated by Maven). The tools would fall down quite easily once we agree on what's necessary.
Regarding AntLib itself, XML descriptor or not, I'm more interested in being able to partition the namespace used by Ant to perform the name to class mapping currently restricted to tasks/types. Maybe something along the lines of Digester, where you can specify a simplified XPath to indicate when a mapping should occur (current mappings are all implicit /**/name or //name to be more XPath compliant), or some role as discussed recently. IMO, if an AntLib doesn't allow specifying a custom Selector, or a custom implementation of a custom interface (by a custom task), both of which configurable using the regular attributes/elements Ant rules, then it's a failure. Peter's proposal, and to a lesser extend mine, both allow to do that, by polluting the types namespace though, and by requiring changes to Tasks/Types to accept custom extensions/beans. In summary, AntLib would finally make Ant pluggable, without requiring to modify its source code every time something needs to be added, just to add a addXXX, or createXXX method, for both built-in tasks, and custom tasks. I don't care much if it uses properties files or XML descriptors for the purpose. --DD
