ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <>
Subject Re: Ant book review in JavaPro July 2003
Date Wed, 09 Jul 2003 10:59:38 GMT
I think you should look at <classloader/> in
the cvs head.

It's purpose is to do exactly what you require.

At one stage it worked, but I think it got broken
when the classpath utility class got added.

I had a look at getting it to work again but
got "blown out of the water".


On Wed, 2003-07-09 at 10:31, Kirk Pepperdine wrote:
> At 11:06 AM 7/1/2003 -0400, you wrote:
> >Kirk - thanks for the kind words!
> >
> >On Monday, June 30, 2003, at 03:16  PM, Kirk Pepperdine wrote:
> >>As for involvement here, I admit to being a lurker :)
> >
> >We're still waiting for your classloader fixes for Ant that we discussed 
> >last November :))  (i.e. making it so junit.jar is not needed in the 
> >classpath running Ant).
> well.. believe it or not.. it's still on my todo stack. But since we are on 
> the subject... here is how I was planning on doing it.
> 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.
> As an alternative to point 3, we could add an attribute to the taskdef task.
> Opinions, suggestions....  concert schedule????
> either way, this looks so incredibly simple that I think that I'll move it 
> up the stack.
> >         Erik
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> >For additional commands, e-mail:
> Cheers,
> Kirk
> "Don't be loath to discard your 'beautifully complex' solutions
> and substitute them with your undramatically simplest
> solutions. And do that again and again until it looks so
> obviously simple that everyone will say, 'Anybody could
> design that.'"
> -- Buckminster Fuller

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

View raw message