You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Craig R. McClanahan" <cr...@apache.org> on 2001/05/21 22:28:28 UTC
[Tomcat 4] PROPOSAL: Revision to Build Procedures
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
Re: [Tomcat 4] PROPOSAL: Revision to Build Procedures
Posted by Amy Roh <am...@apache.org>.
+1
Amy
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: <to...@jakarta.apache.org>
Sent: Monday, May 21, 2001 1:28 PM
Subject: [Tomcat 4] PROPOSAL: Revision to Build Procedures
> 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
>
>
Re: [Tomcat 4] PROPOSAL: Revision to Build Procedures
Posted by kevin seguin <se...@motive.com>.
+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
Re: [Tomcat 4] PROPOSAL: Revision to Build Procedures
Posted by Remy Maucherat <re...@betaversion.org>.
Quoting "Craig R. McClanahan" <cr...@apache.org>:
> 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.
+1
Remy
Re: [Tomcat 4] PROPOSAL: Revision to Build Procedures
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
+1 I was working on doing the same for jakarta-taglibs
"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
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: [Tomcat 4] PROPOSAL: Revision to Build Procedures
Posted by Jon Stevens <jo...@latchkey.com>.
on 5/21/01 1:28 PM, "Craig R. McClanahan" <cr...@apache.org> 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.
+1
> * Dispense with "build.bat" and "build.sh" scripts, because we will be
> executing Ant directly.
+1
> * 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.
+10000000000000000000000000
I hate env variables.
> * 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).
+1
> * 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).
+1
> * 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.
+1
> * 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.
Hmmm...I would like things to build straight out of CVS with as few
modifications and setup if at all possible. In other words, I would prefer
to see build.properties in the directories with all of the "defaults"
necessary. Then, anything that needs to be overridden should be added to
~/build.properties
That way, people can check things out of CVS and simply override anything
that needs it without having to rename files AND do the override.
> * 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.
I don't think you need to sell this group on these benefits.
> * Now, to execute a build, you simply type
> ant dist
> instead of "./build.sh dist" or "build dist" depending on platform.
Yup.
> If this proposal is accepted, I'll go ahead and do the necessary grunt
> work this week.
>
> Comments? Questions?
Have fun. :-)
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
Re: [Tomcat 4] PROPOSAL: Revision to Build Procedures
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Craig R. McClanahan at craigmcc@apache.org 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?
It seems a reasonable (and nedeed :) simplification of the build process...
+1 :P
Pier
Re: [Tomcat 4] PROPOSAL: Revision to Build Procedures
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Craig R. McClanahan at craigmcc@apache.org 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?
It seems a reasonable (and nedeed :) simplification of the build process...
+1 :P
Pier