> From: Dominique Devienne [mailto:[EMAIL PROTECTED] > > 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. >
I agree with you in principle, but it is more than just a contract that we need to agree, there is also all the issues with respect to execution in the presence of antlibs (should they be inherited in ant calls? How redefinitions are treated? all this in the context of things like the <import> task and such). > 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. > The current proposal uses the Role approach. You can define Roles, you can say that a class belongs to a Role and there where changes (not sure how finalized) to the introspectors to connect the two in an element definintion. I wanted to be able to rename imported tasks in case of collision with others comming from different antlibs. I am not sure how XPath could be use to specify roles with that in mind. > 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. > We will always would have to change something :-) And you will always will need collaboration from the tasks that accepr a particular Role. What concerns me is that over time every feature of ANT has define its own separate and divergent mechanist for adding new implementations. On of the objectives of ANTLIB woulb be to settle on on mechanism ( modulo backward compatibility) that all existend and future tasks must support and hence obtain more simetry. > 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 > This has been my dream, since day one of ANTLIB. Now lets take a look at the proposal and let us know what you guys think of it. Jose Alberto
