Académique Documents
Professionnel Documents
Culture Documents
http://www.apache.org/licenses/LICENSE-2.0
====================================================
Building The Apache Tomcat 7.0 Servlet/JSP Container
====================================================
This subproject contains the source code for Tomcat 7.0, a container that
implements the Servlet 3.0, JSP 2.2, EL 2.2 and WebSocket 1.1 specifications
from the Java Community Process <http://www.jcp.org/>.
Note: If you just need to run Apache Tomcat, it is not necessary to build
it. You may simply download a binary distribution. It is cross-platform.
Read RUNNING.txt for the instruction on how to run it.
2. Download a version 6 of the Java Development Kit (JDK) release (use the
latest update available for your chosen version) from
http://www.oracle.com/technetwork/java/javase/downloads/index.html
or from another JDK vendor.
See Apache Commons DBCP project web site for more details on
available versions of the library and its requirements,
http://commons.apache.org/dbcp/
3. Install the Java 6 JDK according to the instructions included with the
release.
5. Download a version 7 of the Java Development Kit (JDK) release (use the
latest update available for your chosen version) from
http://www.oracle.com/technetwork/java/javase/downloads/index.html
or from another JDK vendor.
6. Install the Java 7 JDK according to the instructions included with the
release.
* NOTE: The Java 7 JDK is only required if you wish to build Tomcat with
JSR-356 (Java WebSocket 1.1) support.
http://ant.apache.org/bindownload.cgi
For the purposes of the remainder of this document, the symbolic name
"${ant.home}" is used to refer to the full pathname of the release
directory.
Checkout the source using SVN, selecting a tag for released version or
trunk for the current development code, or download and unpack a source
package.
http://tomcat.apache.org/download-70.cgi
The location where the source has been placed will be further referred as
${tomcat.source}.
The Tomcat local build process does not modify line-endings. The svn repository
is configured so that all files will be checked out with the line-ending
appropriate for the current platform. When using a source package you should
ensure that you use the source package that has the appropriate line-ending
for your platform:
Note that the release build process does modify line-endings to ensure that
each release package has the appropriate line-endings.
(3.2) Building
* NOTE: The default value of the base.path property configures the build script
to download the libraries required to build Tomcat to the
${user.home}/tomcat-build-libs directory.
* NOTE: Users accessing the Internet through a proxy must use the properties
file to indicate to Ant the proxy configuration.
proxy.use=on
proxy.host=proxy.domain
proxy.port=8080
proxy.user=username
proxy.password=password
See Apache Ant documentation for the <setproxy> task for details.
* NOTE: Users wishing to build Tomcat with JSR-356 (Java WebSocket 1.1) support
must also set the java.7.home build property to the location of the Java 7 JDK
installation.
cd ${tomcat.source}
ant
Note that the build includes Tomcat documentation, which can be found
in the output/build/webapps/docs directory.
* NOTE: Do not run the build as the root user. Building and running Tomcat
does not require root privileges.
cd ${tomcat.source}
ant
There are several targets in Tomcat build files that are useful to be
called separately. They build components that you may want to build
quickly, or ones that are included in the full release and are not built
during the default "deploy" build.
cd ${tomcat.source}
ant build-docs
output/build/webapps/docs
The API documentation (Javadoc) is built during a "release" build. It is
easy to build it separately by using the following commands:
cd ${tomcat.source}
ant javadoc
output/dist/webapps/docs/api
output/dist/webapps/docs/elapi
output/dist/webapps/docs/jspapi
output/dist/webapps/docs/servletapi
cd ${tomcat.source}
ant extras
cd ${tomcat.source}
ant embed
(6) Building a full release (as provided via the ASF download pages)
cd ${tomcat.source}
ant release
(7) Tests
Tomcat includes a number of junit tests. The tests are not run when a
release is built. There is separate command to run them.
cd ${tomcat.source}
ant test
The JUnit reports generated by the tests will be written to the following
directory:
output/build/logs
execute.test.bio=true
execute.test.nio=true
execute.test.apr=true
The APR connector can be tested only if Tomcat-Native library binaries are
found by the testsuite. The "test.apr.loc" property specifies the directory
where the library binaries are located.
output/build/bin/native/
If you are on Windows and want to test the APR connector you can put the
tcnative-1.dll file into ${tomcat.source}/bin/native/ and it will be copied
into the above directory when the build runs.
* NOTE: If you configured the build to use a Java 7 JDK (if the
"java.7.home" property has been defined) the tests will be run with Java 7.
The version of Java that was actually used to run the tests is reported by
"org.apache.catalina.util.TestServerInfo" test class.
(7.2) Running a single test
For example:
test.entry=org.apache.catalina.util.TestServerInfo
For example:
test.entry=org.apache.el.lang.TestELArithmetic
test.entry.methods=testMultiply01,testMultiply02
You can include multiple patterns by concatenating them with a comma (",")
as the separator.
For example:
test.name=**/TestSsl.java,**/TestWebSocketFrameClientSSL.java
You can exclude specific JUnit test classes by adding the "test.exclude"
property to the build.properties file. The property specifies an Ant
excludes pattern for the fileset of test class files to exclude form the run.
The default value is empty, so no classes are excluded. The syntax is the same
as for the property "test.name".
output/build/logs
test.accesslog=true
output/build/logs
The log files will be written to the temporary directory used by the
tests,
output/test-tmp/logs
junit.formatter.usefile=false
test.cobertura=true
output/coverage
6. The performance tests are written to run reasonably powerful machines (such
as a developer may use day to day) assuming no other resource hungry
processes are running.
test.excludePerformance=true
7. Some tests include checks that the access log valve entries are as expected.
These checks include timings. On slower / loaded systems these checks will
often fail. The checks may be relaxed by using the following property:
test.relaxTiming=true
java.net.preferIPv4Stack=true
test.verbose=true
(8.1) Checkstyle
Tomcat comes with a Checkstyle configuration that tests its source code
for certain conventions, like presence of the license header.
execute.validate=true
output/res/checkstyle
cd ${tomcat.source}
ant -Dexecute.validate=true validate
You usually would not need to run this check. You can skip this section.
Apache Tomcat project has convention that all of its textual source files,
stored in Subversion repository, are marked with Subversion property
"svn:eol-style" with value of "native". This convention makes the editing
of source code on different platforms easier.
This test is used by developers to check that the source code adheres to
this convention. It verifies that the ends of lines in textual files are
appropriate for the operating system where it is run. The idea is to run
this check regularly on two different platforms and notify developers when
an inconsistency is detected.
cd ${tomcat.source}
ant validate-eoln