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 13:14:34 GMT

>Von: Stefan Bodewig []
>Gesendet: Freitag, 19. September 2003 14:49
>Betreff: Re: new Launcher and CLASSPATH
>On Fri, 19 Sep 2003, Antoine Lévy-Lambert <>
>> I am a bit concerned about the fact that CLASSPATH is ignored by the
>> new launcher.
>But the old launcher (Main) will still work the same way.
>> There are lots of scripts which invoke ant as script, and set
>> CLASSPATH to include different libraries.
>You mean ant the wrapper script or Ant the Java program.  In the later
>case, they'll use Main as their entry point and nothing is going to
>break.  The former case has to be strongly documented.
I am meaning ant as wrapper script.

>> 1) change the ant startup script
>> - do not include CLASSPATH in LOCALCLASSPATH
>> - pass the CLASSPATH as suggested next to a -lib flag
>One of the reasons for the new launcher has been a command line length
>limitation.  With this approach the command line would even become
>longer, I'm afraid.

No the size of the command line would remain the same

the current command line is

java -cp $CLASSPATH:ant-launcher.jar ...

I want to change it to :

java -cp ant-launcher.jar -lib $CLASSPATH

This is just adding 5 characters

>> 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 ?
>To be honest, it never has.
>build.sysclasspath=only has always included the jars from ANT_HOME/lib
>if you used the wrapper script (as the script added them to the
>CLASSPATH), so it has always added things to the CLASSPATH.  The new
>Launcher will still do so.

Then we need to change our documentation. I will try to write the testcases,
it is an interesting exercise.

>> 4) does the launcher solve the problem that ant 1.5 was requiring in
>> CLASSPATH some libraries which are loaded by the java runtime.
>I assume you mean something like
>The new Launcher doesn't solve that, but that we are now splitting up
>optional.jar makes solution (2) a lot easier.
Yes, this is what I am talking about. Can you explain how the splitting of
optional.jar will make the solution easier ?

If you have this scenario :

- custom task
- java runtime class or interface called by the custom task (example
- other library (JNDI driver)

then the other library has to be in the CLASSPATH.



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

View raw message