Defines and loads elements contained in an ANT library. It also allows the aliasing of the names being defined in order to avoid collisions and provides means to override definitions with the ones defined in the library. Ant libraries are associated with ClassLoaders identified by the loaderid attribute. If no loader is specified a default loader will be used. Ant libraries specifying the same loader are loaded by the same ClassLoader as long as the libraries are defined on the same project. Classloaders with the same ID in a subproject have the corresponding classloader in the parent project as their parent classloader.
Ant libraries can be loaded in the current classloader, which is more efficient, but requires the tasks to be in the path already (such as in the ant lib directory) - set useCurrentClassloader to true to enable this. It is also possible to add more libraries to the path, such as any libraries the task is dependent on. Ant libraries define objects of several types: Roles: Define an interface to be implemented by elements (usually tasks) that accept subelements of the specified role. Roles may also define a proxy class which may be applied to an element in order to make it compatible with the role. Tasks: define elements that belong to the predefined role "task". Data types: define elements that belong to the predefined role "datatype". Other role elements: declare elements for other roles that have been previously defined. Antoine ----- Original Message ----- From: "Dominique Devienne" <[EMAIL PROTECTED]> To: "'Ant Developers List'" <[EMAIL PROTECTED]> Sent: Tuesday, April 22, 2003 4:13 PM Subject: RE: antlib > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
