I'd like to propose a modification to the way that the build scripts for
Tomcat 4 work, based on experience gained in the Jakarta Commons project,
Struts, and a couple of non-Jakarta projects that use the same approach.
Basically, the changes go like this:
* Ant must be installed as an application, and $ANT_HOME/bin must be
on your PATH environment variable so that the "ant" command can be
used directly from the shell command prompt.
* Dispense with "build.bat" and "build.sh" scripts, because we will be
executing Ant directly.
* Dispense with environment variables to point at all of the dependencies.
This will be replaced by references in "build.properties" files as
discussed further below.
* The top-level build.xml script for Tomcat will include the lines:
<property file="build.properties"/>
<property file="${user.home}/build.properties"/>
so that values specific to your environment can be set locally (i.e.
in the top level "jakarta-tomcat-4.0" directory, or globally (in
your user home directory).
* Because of the way that Ant works, these conventions create an ordered
hierarchy for property assignment (first definition wins):
- User's properties that are specific to this project
- User's global properties file (in the user.home directory)
- Default properties declared in build.xml (after the lines above).
* Subordinate build.xml scripts (in catalina, jasper, etc.) will include:
<property file="build.properties"/>
<property file="../build.properties"/>
<property file="${user.home}/build.properties"/>
so that you can use "ant" directly in those directories as well, and
still pick up all of your local dependencies.
* Because the "build.properties" files are local to your development
system, they are *not* checked in to CVS (in fact, they will get
added to the ".cvsignore" list). However, an example properties file
"build.properties.sample" will be checked in that documents the
variables that must, or can, be set.
* Besides being easier (than environment variables) to manipulate, using
properties files in this way has several advantages:
- Using "${user.home}/build.properties" lets you share property
assignments across all projects using the same conventions.
- Using "build.properties" lets you override global property settings
for a different project (say, for example, that you want to use a
different XML parser for building Tomcat than for building other
projects).
- You can do variable substitutions in your "build.properties" settings
just like you can when setting properties explicitly - Ant resolves
them when the properties files are loaded.
* Now, to execute a build, you simply type
ant dist
instead of "./build.sh dist" or "build dist" depending on platform.
If this proposal is accepted, I'll go ahead and do the necessary grunt
work this week.
Comments? Questions?
Craig
