tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Luby <>
Subject Re: cvs commit: jakarta-tomcat-5 build2.xml
Date Sun, 04 Aug 2002 17:39:21 GMT

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
- Syncronized starting and stopping of the build process so that other
   applications (e.g. commons-daemon) can start Ant and kill Ant
- 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.



Patrick Luby                     Email:
Sun Microsystems                         Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900

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

View raw message