ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Reilly <>
Subject Re: antlib and classloaders
Date Fri, 02 Apr 2004 11:25:39 GMT
Mariano's original question was why
was classpath ignored in an antlib definition.

   <typedef name="task" classname="org.mytasks.Task" loaderref="mytasks.ref">
         <fileset dir="${env.MY_TASKS_HOME}/lib" includes="**/*.jar"/>
    <typedef name="task2" classname="org.mytasks.Task2" loaderref="mytasks.ref"/>

This could be supported easily in the current code base.
-i.e. if an typedef/taskdef in an antlib sets the classpath, this classpath will be used instead
of the antlibdefinition classpath.

The only problem with this is that the user build script needs to set the correct property
before the antlib is activated.


Mariano Benitez wrote:

> I have this issue in mind:
> Since I need to provide antlibs to my customers, I would like them to 
> have to manually configure as less as possible, that means that the 
> previous way of saying -b <myapp>/antlib was quite cool.
> The problem is that I do need to control the classloader where the 
> tasks are loaded, because I cannot copy the whole list of jars in my 
> app to the antlib classpath. Maybe by just copying ONE jar to antlib 
> is just fine, and inside the antlib.xml control the classloading. 
> Maybe only making the antlib.xml file available in the ant base 
> classpath would be another way.
> Following your proposal, inside my antlib.xml I would define the 
> classpath for the antlib itself, leaving all configuration inside 
> there, and not having to manually define a classpath outside the 
> antlib. I know this can be achieved by using an <import> task, that is 
> the solution I will implement in 1.6.1, but having all the 
> classloading issues inside the antlib file itself is more simple for 
> the user of the antlib. Also reduces the main ant classpath.
> Well, those are my 2 cents, hope is clear, antlibs are great and I 
> would like them to keep evolving and making it better.
> MAriano
> Jose Alberto Fernandez wrote:
>> Hi, I have been giving some thought on ways to solve this nagging
>> issue of needing to put antlib jars on the lib directory.
>> We hear over and over people wanting to keep their third party
>> libraries out of -lib because they are only for an specific project.
>> As I see it, our road block has been how to tell in succinct way in the
>> buildfile that when loading the namespace "" you should
>> use this or that classpath or classloader.
>> A simple solution could be to achieve this by name association:
>> - When ANT tries to find and load the resource for ""
>> it will first look for a reference named "" representing
>> a classloader (or classpath?). If an object of the correct type is
>> found, then this classloader will be user for resolving and loadding
>> the antlib, otherwise the default classloader will be use, as it is
>> today.
>> So with this in place, one could write things like:
>> <project name="x" xmlns:lib="">
>>  <classpath id="">.....</classpath>
>>  <lib:mytask ..../> <!-- The antlib loaded using the classloader for
>> "" -->
>> </project>
>> Before jumping on a code proposal, does this sound a the right or good
>> solution? Does this cover enough of the use cases?
>> Let me know what you people think.
>> Jose Aberto
>> ------------------------------------------------------------------------
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message