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). (2) Fix all tasks that load classes - like Definer - to delegate to the classloader created in Launcher instead of the system classloader. I think this can mostly be done by changing AntClassLoader to consult the context classloader before delegating to the parent, but I'm not sure whether this would break any other use case. Or the classloader created in Launcher must be the parent of the created AntClassloader instances (probably the better solution). We may need to search for plain Class.forName invocations as well. 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. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
