Mariano's original question was why was classpath ignored in an antlib definition.
<antlib>
<typedef name="task" classname="org.mytasks.Task" loaderref="mytasks.ref">
<classpath>
<fileset dir="${env.MY_TASKS_HOME}/lib" includes="**/*.jar"/>
</classpath> <typedef name="task2" classname="org.mytasks.Task2" loaderref="mytasks.ref"/>
</antlib>
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.
Peter
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 "antlib:foo.bar" 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 "antlib:foo.bar" it will first look for a reference named "foo.bar" 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="antlib:foo.bar">
<classpath id="foo.bar">.....</classpath>
<lib:mytask ..../> <!-- The antlib loaded using the classloader for "foo.bar" -->
</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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
