Re: Antlibs and Classloaders

Hello Stefan,

On 01/08/26 3:06 pm, Stefan Bodewig wrote:
> ...
>
> Right now I'm using an extremely crude workaround that downloads Ivy,
> <typedef>s it, Ivy then downlads the Antlib and its dependencies, I
> <typedef> the Antlib and give the classloader a name, then I <typedef>
> Ivy once again using the same classloader and run <ivy:resolve> a second
> time. This is not the way it should be IMHO.
>
> There is a built-in way in Ant, the <classloader> task - something that
> is dirty little secret so much that we don't even document it. This
> could either be used to inject Ivy into Ant's core loader - or I could
> define the classloader for the Antlib and set it up to use the
> classloader that is used by Ivy as its parent. This should work. If this
> is an approach we want to recommend, we probably should make the task
> "official".
>
> Another idea would be to allow <typedef> to optionally specify the
> parent classloader. This would allow the setup of the paragraph above
> without the use of the classloader task - but requires a change to Ant.
>
> Any other ideas? Any preferences?

My worries with introducing any feature related to classloaders is that 
as soon as it gets used widely, chances are that users will run into odd 
classloading issues either due to advanced usages or just because of the 
complexity involved with classloaders.

I wasn't aware we had a "classloader" task already. If that works 
currently for the AntLibs usage, then I think we should use it. I think 
AntLibs is somewhat special in that they are a bit closer to the Ant 
project itself and are limited in their number 
https://ant.apache.org/antlibs/proper.html. So using an "internal 
detail" of Ant (i.e. the classloader task) I think is OK. That then 
means that it gives us some more time and usage experience to decide if 
we do want to make the classloader task official.

-Jaikiran