ytzh: переводы

→Using the development and testing targets requires some additional one-time setup that is described on the next page.

→remove - When you have completed your development and testing activities, you can optionally tell Tomcat to remove this application from service.

→reload - Once the application is installed, you can continue to make changes and recompile using the compile target. Tomcat will automatically recognize changes made to JSP pages, but not to servlet or JavaBean classes - this command will tell Tomcat to restart the currently installed application so that such changes are recognized.

→install - Tell the currently running Tomcat to make the application you are developing immediately available for execution and testing. This action does not require Tomcat to be restarted, but it is also not remembered after Tomcat is restarted the next time.

→For interactive development and testing of your web application using Tomcat, the following additional targets are defined:

→dist - This target creates a distribution directory for your application, including any required documentation, the Javadocs for your Java classes, and a web application archive (WAR) file that will be delivered to system administrators who wish to install your application. Because this target also depends on the deploy target, the web application archive will have also picked up any external dependencies that were included at deployment time.

→javadoc - This target creates Javadoc API documentation for the Java classes in this web application. The example build.xml file assumes you want to include the API documentation with your app distribution, so it generates the docs in a subdirectory of the dist directory. Because you normally do not need to generate the Javadocs on every compilation, this target is usually a dependency of the dist target, but not of the compile target.

→all - This target is a short cut for running the clean target, followed by the compile target. Thus, it guarantees that you will recompile the entire application, to ensure that you have not unknowingly introduced any incompatible changes.

→compile - This target is used to compile any source code that has been changed since the last time compilation took place. The resulting class files are created in the WEB-INF/classes subdirectory of your build directory, exactly where the structure of a web application requires them to be. Because this command is executed so often during development, it is normally made the "default" target so that a simple ant command will execute it.

→clean - This target deletes any existing build and dist directories, so that they can be reconstructed from scratch. This allows you to guarantee that you have not made source code modifications that will result in problems at runtime due to not recompiling all affected classes.

→To give you a head start, a basic build.xml file is provided that you can customize and install in the project source directory for your application. This file includes comments that describe the various targets that can be executed. Briefly, the following targets are generally provided:

→ant -projecthelp

→Like a Makefile, the build.xml file provides several "targets" that support optional development activities (such as creating the associated Javadoc documentation, erasing the deployment home directory so you can build your project from scratch, or creating the web application archive file so you can distribute your application. A well-constructed build.xml file will contain internal documentation describing the targets that are designed for use by the developer, versus those targets used internally. To ask Ant to display the project documentation, change to the directory containing the build.xml file and type:

→We will be using the ant tool to manage the compilation of our Java source code files, and creation of the deployment hierarchy. Ant operates under the control of a build file, normally called build.xml, that defines the processing steps required. This file is stored in the top-level directory of your source code hierarchy, and should be checked in to your source code control system.

→BUILD.XML Configuration File

→CVS, like other source code control systems, has many additional features (such as the ability to tag the files that made up a particular release, and support for multiple development branches that can later be merged). See the links and references in the Introduction for more information.

→While you are creating, modifying, and deleting source files, changes are not yet reflected in the server repository. To save your changes in their current state, go to the project source directory and execute cvs commit. You will be asked to write a brief description of the changes you have just completed, which will be stored with the new version of any updated source file.

→If you no longer need a particular source code file, navigate to the containing directory and remove the file. Then, deregister it in CVS with a command like cvs remove {filename}.

→When you first create a new source code file, navigate to the directory that contains it, and register the new file with a command like cvs add {filename}.

→When you create a new subdirectory in the source code hierarchy, register it in CVS with a command like cvs add {subdirname}.