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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
