ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Lévy-Lambert <>
Subject AW: new Launcher and CLASSPATH
Date Fri, 19 Sep 2003 12:32:24 GMT

I am a bit concerned about the fact that CLASSPATH is ignored by the new
This is a breach of behavioral compatibility.
There are lots of scripts which invoke ant as script, and set CLASSPATH to
include different libraries.

If it is possible to set the extra libraries needed by the users in Main, I
have an idea of a workaround :

1) change the ant startup script
- pass the CLASSPATH as suggested next to a -lib flag

2) process the path passed in the -lib flag in Main

Would this solution be OK ?

3) testcases : would using the <java/> task with fork set to true and main
class set to Launcher allow us to test that build.sysclasspath behaves as
documented ?

4) does the launcher solve the problem that ant 1.5 was requiring in
CLASSPATH some libraries which are loaded by the java runtime. For instance,
with ant 1.5, a custom task using JNDI (javax.naming.Context) requires the
JNDI drivers in the CLASSPATH before ant gets started. Is this problem
supposed to be fixed in ant 1.6 (with the custom task working if the JNDI
drivers are in the nested classpath element of taskdef, rather than in


-----Urspr√ľngliche Nachricht-----
Von: Conor MacNeill []
Gesendet: Donnerstag, 18. September 2003 15:37
An: Ant Developers List
Betreff: Re: new Launcher and CLASSPATH

On Wed, 17 Sep 2003 08:29 pm, Stefan Bodewig wrote:
> So far all our documentation more or less states that putting your jar
> containing custom tasks into ANT_HOME/lib or pointing to it in your
> CLASSPATH was equivalent.  This is no longer true if the new launcher
> is used.


> As ant.jar cannot be found on the system classloader anymore, any
> class loaded from the system classloader (i.e. classes coming from
> CLASSPATH) can't load the Task class for example.
> I see two options:
> (1) live with it and document it properly (which means people may have
> to link/copy a lot into ANT_HOME/lib).

Yes. I think we should recommend that Ant be run with an empty CLASSPATH. I
have added an option ot read libs out of a home directory and would like to
add an option to specify arbitrary lib directories with a -lib option or
similar. The only drag is that the command processing would need to be done
in the launcher to extract this info and then pass the rest of the command
line to the Main class.

> (2) Fix all tasks that load classes - like Definer - to delegate to
> the classloader created in Launcher instead of the system classloader.

I don't think this will work. No matter which classloader you use to find
class, if it is found on the system class loader it will try to load
dependent classes with the same loader.

>  Or the classloader
> created in Launcher must be the parent of the created AntClassloader
> instances (probably the better solution).

I expect that to be the case anyway.

> Also, I'm not sure whether build.sysclasspath is going to work as
> expected when used with the new launcher.  It seems as if the code in
> Launcher that resets the java.class.path system property should take
> care of it, but I'm not entirely sure.  If we wanted to test it via
> Gump (which uses build.sysclasspath=only), we first need to find a
> solution for my first issue above.

True - may not be compatible with my empty CLASSPATH recommendation above.


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

View raw message