+1
"Craig R. McClanahan" wrote:
>
> 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
