One big caveat to adding custom extensions to Antlion into Ant is the classpath.
If you're putting all the Antlion libraries into the Ant lib
directory, then you have nothing to worry about. Just add the tasks as you
normally would through Ant <taskdef>
tasks, and skip the rest of this
section.
However, if you put Antlion in its own classpath, then there are some hurdles
to tackle. To be rather technical, extensions must either be in the same
classloader or a child classloader to the ones containing Antlion. This means
that, to load Antlion jars outside of the Ant library, you need to do something
like the following:
|
|
|
|
<path id="lib.antlion">
<pathelement location="${lib.dir}/antlion-inline-0.9.0.jar" />
<pathelement location="${lib.dir}/extended-antlion.jar" />
</path>
<taskdef resource="net/sf/antlion/antlib.xml"
classpathref="lib.antlion"
loaderref="lib.antlion.loader" />
<taskdef name="my-extension-task"
classname="my.CustomTask"
loaderref="lib.antlion.loader" />
|
|
|
|
|
There are some alternatives available. For instance, you can join these
<taskdef>
declarations into a single statement, and use a custom
antlib.xml
resource:
|
|
|
|
<antlib>
<typedef resource="antlion-libraries-types.properties" />
<taskdef resource="antlion-libraries.properties" />
<taskdef resource="antlion-extentions.properties" />
</antlib> |
|
|
|
|
In the case of a custom token formatter, the options are the same. When
loading the formatter directly from ant, the taskdef would look something like:
|
|
|
|
<typedef name=".antlion.token-formatter-factor"
classname="org.acme.formatter.CustomTokenFormatterFactory"
loaderref="lib.antlion.loader" />
|
|
|
|
|
whereas in the custom antlib.xml
could load the taskdef using
only the name
and classname
attributes.