This task has been deprecated in favor of the <library-policy> tag. It will be removed in Antlion 1.0.

A library type defines a collection of processors, and how they are set up, that gets associated with <libraryDef> elements.

A word of caution about <library-type>s: the more you have, the more difficult it is to debug a build script. A <library-type> should be thought of as part of a project-wide policy regarding how libraries modify an Ant project. Settle on a single type, and tweak that type to perform the necessary actions on all sub-projects. Therefore, the author recommends putting this inside a <library-policy>, and using that in the <libraryDef>.

You can find a list of all the current built-in processors here, along with a description about the execution order of them.

Nested Elements

default processor type Adds all the default processors in the current type. The first example below details all the default processors.

Examples

<library-type id="antlion.library-type.default"> <path /> <fileset /> <attribute attributes="groupid, group, version" /> <manifest-classpath /> <property> <format text="[groupid].[artifactid]-[current].[type]" /> <format text="[groupid].[artifactid]-[version].[type]" /> <format text="[group].[artifact]-[current].[type]" /> <format text="[group].[artifact]-[version].[type]" /> </property> </library-type> Creates a library-type that matches the <libraryDef> default type. <libraryDef> elements would use this by including the child element <type refid="antlion.library-type.default>. <property name="lib.junit.version" value="3.8.1" /> <property name="lib.xerces.version" value="2.6.2" /> <property name="lib.ant.version" value="1.6.2" /> <libraryDef> <repository ... /> <type> ... <dynamic-attribute> <attribute attrib="version" property="lib.[group].version" /> </dynamic-attribute> </type> <library> <lib-entry group="junit" artifact="junit" /> <lib-entry group="xerces" artifact="xercesImpl" /> <lib-entry group="ant" artifact="ant-optional" version="1.5.3" /> </library> </libraryDef> This example shows one way that the <dynamic-attribute> can be useful. The <lib-entry> for junit will first be processed by the dynamic attribute. This will see that the "version" attribute wasn't set in the entry, and will try to set it from the property ${lib.junit.version}, replacing the [group] format with the corresponding attribute value. The same thing happens with the xerces lib-entry. With the ant lib-entry, since the version attribute is already set, the dynamic-attribute processor does not override this, and leaves it at the existing value of "1.5.3".