>Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] >Gesendet: Freitag, 19. September 2003 14:49 >An: [EMAIL PROTECTED] >Betreff: Re: new Launcher and CLASSPATH > > >On Fri, 19 Sep 2003, Antoine Lévy-Lambert <[EMAIL PROTECTED]> >wrote: > >> 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 org.apache.tools.launch.Launcher ... I want to change it to : java -cp ant-launcher.jar org.apache.tools.launch.Launcher -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 ><http://ant.apache.org/faq.html#delegating-classloader>. > >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 javax.naming.Context) - other library (JNDI driver) then the other library has to be in the CLASSPATH. Cheers, Antoine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
