ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik hatcher <>
Subject Ant's ClassLoader [was: Re: Ant book review in JavaPro July 2003]
Date Sat, 19 Jul 2003 00:51:35 GMT
My apologies for delaying my reply....

On Wednesday, July 9, 2003, at 05:31  AM, Kirk Pepperdine wrote:
> Since diddling with a fully configured, loaded and running classloader 
> can really blow you out of the water, I wanted to take some time to 
> think about this (yeah that's it... think time). Here is what I'd 
> purpose doing.
> 1) Verify that ANT is contained with-in it's own classloader.
> 2) add a method to the classloader to expose the currently protected 
> method used to add classpath elements. At issue here is that if 
> different threads pick the same things up from different classloaders, 
> you'll end up with some expection being thrown such as a class not 
> found which can be confusing because when you go to check you 
> classapth, you'll find the class 8^) Danger, having jUnit on the 
> classpath and then having it show up in configuration BAD!!!
> 3) add a new property type known as jar. It would look something like
> <property jar="${}/junit.jar"/> This would have to reached 
> and acted upon before any references were made to the junit (or other) 
> classes.

How do your plans jive with the latest stuff that Conor has done with 
the Launcher and the loaderRef stuff that can be done on <taskdef>?

> As an alternative to point 3, we could add an attribute to the taskdef 
> task.

Like loaderRef?  Or different?


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

View raw message