Hi, I am a bit concerned about the fact that CLASSPATH is ignored by the new launcher. 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 - do not include CLASSPATH in LOCALCLASSPATH - 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 CLASSPATH ?) Antoine -----Ursprüngliche Nachricht----- Von: Conor MacNeill [mailto:[EMAIL PROTECTED] 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. True. > > 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 the 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. Conor --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
