Costin, Costin Manolache wrote: > > It may be a good idea to move the ant tasks/types that you need from > sandbox into oac.launcher. I think they should be in either tomcat > or ant ( preferably). > > Later on, after things stabilise we can propose it for commons proper. >
I would like to see the <syspropertyset>, <argset>, and <jvmargset> data types and the conditional <sysproperty>, <arg>, and <jvmarg> elements moved to Ant. Also, I should be able to integrate the <launch> task attributes into Ant's <java> task. I just won't be able to do it for a few weeks since my employer has squeezed my spare time down to nothing. But I intend to post patches for this code so that it can go in Ant 1.6. The other half of the Launcher code is merely the bootstrapping of ant.jar (which is where the enhanced data types listed above would be). This code be added to Ant 1.6 very easily as all it does is instantiate a ClassLoader and classload ant.jar. This piece of code deserves more explanation. In the launcher, this bootstrapper is called LauncherBootstrap.class and resides in the same directory as the shell script that users use. Then, in Windows batch scripts, you put %0\..;"%PATH%" as the classpath when invoking Java. Since Windows sometimes makes %0 meaningless, %PATH% is used as the classpath. Since LauncherBootstrap.class is an unjarred class in %PATH% (since it is in the same directory as the script), it will get included in the classpath. LauncherBootstrap.class then just loads ant.jar since Java can reliably determine which directory LauncherBootstrap.class was loaded from. In essence, the whole bootstrapping process is a hack to get around the %0 problem on Windows 95, 98, ME, and sometimes 2000. So, it might be useful to include this bootstrapper in Ant so that the Ant batch scripts can find its classes. There were a few other things that are in the Launcher which may be useful if ported to Ant: - Catching of uncaught Errors (e.g. OutOfMemoryError) and gracefully exiting - Syncronized starting and stopping of the build process so that other applications (e.g. commons-daemon) can start Ant and kill Ant directly. - Retrieve localized strings so that we can localize BuildExceptions and <echo> and <fail> messages. If the Ant committers accept my patches, effectively moving all of the Launcher functionality into Ant 1.6, then I think the commons-launcher portion of commons-daemon can be made obsolete and commons-daemon could just use Ant 1.6 directly. Right now, commons-daemon needs both commons-launcher.jar *and* ant.jar. Let me know what you think of this approach. Thanks, Patrick -- ________________________________________________________________ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 ________________________________________________________________ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
