Quellcode-Bibliothek

^© Kompilation durch diese Firma

[Weder Korrektheit noch Funktionsfähigkeit der Software werden zugesichert.]

Datei: processes.xml Sprache: XML

Original von: Apache^©

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE document [
 <!ENTITY project SYSTEM "project.xml">
]>
<document url="processes.html">

 &project;

 <properties>
 <author email="[email protected]">Craig R. McClanahan</author>
 <title>Development Processes</title>
 </properties>

<body>

<section name="Table of Contents">
<toc/>
</section>

<section name="Development Processes">

Although application development can take many forms, this manual proposes
a fairly generic process for creating web applications using Tomcat. The
following sections highlight the commands and tasks that you, as the developer
of the code, will perform. The same basic approach works when you have
multiple programmers involved, as long as you have an appropriate source code
control system and internal team rules about who is working on what parts
of the application at any given time.

The task descriptions below do not assume any particular source code control
system but simply identify when and what source code control tasks are typically
performed. You will need to idenitfy the appropriate source code control
commands for your system.

<subsection name="One-Time Setup of Ant and Tomcat for Development">

In order to take advantage of the special Ant tasks that interact with the
Manager web application, you need to perform the following tasks
once (no matter how many web applications you plan to develop).
<ul>
<li>Configure the Ant custom tasks. The implementation code for the
 Ant custom tasks is in a JAR file named
 <code>$CATALINA_HOME/lib/catalina-ant.jar</code>, which must be
 copied in to the <code>lib</code> directory of your Ant installation.
 </li>
<li>Define one or more Tomcat users. The Manager web
 application runs under a security constraint that requires a user to be
 logged in, and have the security role <code>manager-script</code> assigned
 to then. How such users are defined depends on which Realm you have
 configured in Tomcat's conf/server.xml file -- see the
 <a href="../realm-howto.html">Realm Configuration How-To</a> for more
 information. You may define any number of users (with any username
 and password that you like) with the <code>manager-script</code> role.
 </li>
</ul>

</subsection>

<subsection name="Create Project Source Code Directory">

The first step is to create a new project source directory, and customize
the <code>build.xml</code> and <code>build.properties</code> files you will
be using. The directory structure is described in <a href="source.html">the
previous section</a>, or you can use the
<a href="sample/">sample application</a> as a starting point.

Create your project source directory, and define it within your source code
control system. This might be done by a series of commands like this:
<source><![CDATA[cd {my home directory}
mkdir myapp <-- Assumed "project source directory"
cd myapp
mkdir docs
mkdir src
mkdir web
mkdir web/WEB-INF
cvs or svn or git ... <-- Add this structure to the appropriate repository
]]></source>

To verify that the project was created correctly in the source code control
repository, you may wish to check out the project to a separate directory and
confirm that all the expected contents are present.

Next, you will need to create and check in an initial version of the
<code>build.xml</code> script to be used for development. For getting
started quickly and easily, base your <code>build.xml</code> on the
<a href="build.xml.txt">basic build.xml file</a>, included with this manual,
or code it from scratch.
<source><![CDATA[cd {my home directory}
cd myapp
emacs build.xml <-- if you want a real editor :-)
cvs or svn or git ... <-- Add this file to the repository
]]></source>

The next step is to customize the Ant properties that are
named in the <code>build.xml</code> script. This is done by creating a
file named <code>build.properties</code> in your project's top-level
directory. The supported properties are listed in the comments inside
the sample <code>build.xml</code> script. At a minimum, you will generally
need to define the <code>catalina.home</code> property defining where
Tomcat is installed, and the manager application username and password.
You might end up with something like this:
<source># Context path to install this application on
app.path=/hello

# Tomcat installation directory
catalina.home=/usr/local/apache-tomcat-<version-major-minor/>

# Manager webapp username and password
manager.username=myusername
manager.password=mypassword</source>

In general, you will not want to check the
<code>build.properties</code> file in to the source code control repository,
because it is unique to each developer's environment.

Now, create the initial version of the web application deployment
descriptor. You can base <code>web.xml</code> on the
<a href="web.xml.txt">basic web.xml file</a>, or code it from scratch.
<source><![CDATA[cd {my home directory}
cd myapp/web/WEB-INF
emacs web.xml
cvs or svn or git ... <-- Add this file to the repository
]]></source>

Note that this is only an example web.xml file. The full definition
of the deployment descriptor file is in the
<a href="https://cwiki.apache.org/confluence/display/TOMCAT/Specifications">Servlet Specification.</a>

</subsection>

<subsection name="Edit Source Code and Pages">

The edit/build/test tasks will generally be your most common activities
during development and maintenance. The following general principles apply.
As described in <a href="source.html">Source Organization</a>, newly created
source files should be located in the appropriate subdirectory, under your
project source directory.

You should regularly refresh your development directory to reflect the
work performed by other developers.

To create a new file, go to the appropriate directory and create the file.
When you are satisfied with its contents (after building and testing is
successful), add the new file to the repository. For example, to create a new
JSP page:
<source><![CDATA[cd {my home directory}
cd myapp/web <-- Ultimate destination is document root
emacs mypage.jsp
... build and test the application ...
cvs or svn or git ... <-- Add this file to the repository
]]></source>

Java source code that is defined in packages must be organized in a directory
hierarchy (under the src/ subdirectory) that matches the
package names. For example, a Java class named
<code>com.mycompany.mypackage.MyClass.java</code> should be stored in file
<code>src/com/mycompany/mypackage/MyClass.java</code>.
Whenever you create a new file, don't forget to add it to the source code
control system.

To edit an existing source file, you will generally just start editing
and testing, then commit the changed file when everything works.

</subsection>

<subsection name="Build the Web Application">

When you are ready to compile the application, issue the following
commands (generally, you will want a shell window open that is set to
the project source directory, so that only the last command is needed):
<source><![CDATA[cd {my home directory}
cd myapp <-- Normally leave a window open here
ant]]></source>

The Ant tool will be execute the default "compile" target in your
<code>build.xml</code> file, which will compile any new or updated Java
code. If this is the first time you compile after a "build clean",
it will cause everything to be recompiled.

To force the recompilation of your entire application, do this instead:
<source><![CDATA[cd {my home directory}
cd myapp
ant all]]></source>

This is a very good habit immediately before checking in changes, to
make sure that you have not introduced any subtle problems that Javac's
conditional checking did not catch.

</subsection>

<subsection name="Test Your Web Application">

To test your application, you will want to install it under Tomcat. The
quickest way to do that is to use the custom Ant tasks that are included in
the sample <code>build.xml</code> script. Using these commands might follow
a pattern like this:
<ul>
<li>Start Tomcat if needed. If Tomcat is not already running,
 you will need to start it in the usual way.
 </li>
<li>Compile your application. Use the <code>ant compile</code>
 command (or just <code>ant</code>, since this is the default). Make
 sure that there are no compilation errors.
 </li>
<li>Install the application. Use the <code>ant install</code>
 command. This tells Tomcat to immediately start running your app on
 the context path defined in the <code>app.path</code> build property.
 Tomcat does NOT have to be restarted for this to
 take effect.
 </li>
<li>Test the application. Using your browser or other testing
 tools, test the functionality of your application.
 </li>
<li>Modify and rebuild as needed. As you discover that changes
 are required, make those changes in the original source
 files, not in the output build directory, and re-issue the
 <code>ant compile</code> command. This ensures that your changes will be
 available to be saved (via your chosen source code control system) later on
 -- the output build directory is deleted and recreated as necessary.
 </li>
<li>Reload the application. Tomcat will recognize changes in
 JSP pages automatically, but it will continue to use the old versions
 of any servlet or JavaBean classes until the application is reloaded.
 You can trigger this by executing the <code>ant reload</code> command.
 </li>
<li>Remove the application when you are done. When you are through
 working on this application, you can remove it from live execution by
 running the <code>ant remove</code> command.
 </li>
</ul>

Do not forget to commit your changes to the source code repository when
you have completed your testing!

</subsection>

<subsection name="Creating a Release">

When you are through adding new functionality, and you've tested everything
(you DO test, don't you :-), it is time to create the distributable version
of your web application that can be deployed on the production server. The
following general steps are required:
<ul>
<li>Issue the command <code>ant all</code> from the project source
 directory, to rebuild everything from scratch one last time.
 </li>
<li>Use the source code control system to tag the current state of the code
 to create an identifier for all of the source files utilized to create this
 release. This allows you to reliably reconstruct a release (from sources)
 at a later time.
 </li>
<li>Issue the command <code>ant dist</code> to create a distributable
 web application archive (WAR) file, as well as a JAR file containing
 the corresponding source code.
 </li>
<li>Package the contents of the <code>dist</code> directory using the
 tar or zip utility, according to
 the standard release procedures used by your organization.
 </li>
</ul>

</subsection>

</section>

</body>
</document>

¤ Dauer der Verarbeitung: 0.18 Sekunden (vorverarbeitet) ¤

Download des Quellennavigators
Download des sprechenden Kalenders
in der Quellcodebibliothek suchen

Haftungshinweis

Die Informationen auf dieser Webseite wurden nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit, noch Qualität der bereit gestellten Informationen zugesichert.

Bemerkung:

Die farbliche Syntaxdarstellung ist noch experimentell.