ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: What do you think about a <classloader> task ?
Date Mon, 29 Mar 2004 13:35:15 GMT
Rainer Noack wrote:
> Hi Ant developers,
> After taskdef supports the loaderref attribute, I've 
> written a task that is able to 
> a) append classpath entries to existing classloaders, 
> b) explicitely create classloaders,
> c) put the actual path of a classloader into a property and
> d) log a simple report about the currently classloaders.
> Currently it supports URLClassLoader and AntClassLoader. It is 
> designed to simply support custom extensions for any arbitrary 
> ClassLoader.
> I've posted it some time ago - a little rash (sorry) - to this list.
> However, as classpathes can completely managed from inside the build.xml, 
> this task has helped in several projects
> 1. to avoid the need to either change Ant's default installation 
>    by adding or removing jars to or from Ant's lib dir 
>    or manage the classpath in the launching script and
> 2. to avoid classpath-problems with custom tasks 
>    (especially if they should - for whatever reason - be used 
>     as jars in the same buildfile as they were created).

This all seems useful, and is the logical extension of the -lib option 
to insert new stuff into the base classloader.

I am currently busy doing classpath stuff and ant integration with our 
deployment framework (see 
One thing smartfrog does is lets you specify a codebase when describing 
a new app to host/deploy; that codebase takes URLs. now in security on 
mode, only signed and sealed URLs are allowed, but ignoring that detail, 
being able to spec URLs to where jars come from is very, very slick.

Security does matter; you dont want to have build files that go

   <add url="" />

without something saying 'is this a trusted release of junit'.

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

View raw message