Re: antlibs and classloaders #2

[Mariano Benitez]

Peter Reilly wrote:
another thing, I did the <typedef> thing because I cannot add 
classpath to an antlib definition, so the problems are chained....

I hope to get this in for ant 1.6.2.
This is still in a definition process, I guess, so I cannot make any 
work towards this direction.

You would still face the problem.
The antlib: namespace automatic loading of tasks/types is only 
triggered if a task or type from
the namespace is used.

From what you said I understand that the antlib definition is lazy and 
done from the current ant and descendents, not for the whole ant script, 
this is why if the usage of an antlib task is inside subants, then for 
each one another classloader is created. That's why if I define it in 
the top level ant it applies for all subants.

So, I am thinking of the following workaround for the complete scope of 
the problem:

I create a task <antlib> that performs would look like this:
<antlib property="fuego.antlib.defined">
   <classpath>
       <fileset dir="${fuego.basedir}/lib">
           <include name="fuegoexpress-antlib.jar"/>
           <include name="fuegoenterprise-antlib.jar"/>
           <include name="fuegoj2ee-antlib.jar"/>
           <include name="fuego-test-antlib.jar"/>
       </fileset>
   </classpath>
   <typedef package="fuego.tools.ant.enterprise"/>
   <typedef package="fuego.tools.ant.express"/>
   <typedef resource="fuego/tools/ant/j2ee/antlib.xml"/>
   <typedef resource="fuego/internal/test/ant/myFile.xml"/>
</antlib>
Here I would check with the property, and if not set define a 
classloader with that classpath and define the antlibs in that loader, 
just what I do in the import file, but inside a task. I can put this 
task in the ant -lib path, and use it in the import files.

What do you think?
MAriano

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]