アプリケーション開発者ガイド

• ディレクトリ構造
  1. 外部依存性
• ソースコード管理
• BUILD.XML 設定ファイル

以下の説明では、ほとんどの相対パスが解決される基準ディレクトリを参照するために、変数名 $CATALINA_BASE を使用します。CATALINA_BASE ディレクトリを設定してTomcatを複数インスタンス用に構成していない場合、$CATALINA_BASEはTomcatをインストールしたディレクトリである$CATALINA_HOMEの値に設定されます。

このマニュアルの重要な推奨事項は、ソースコードを含むディレクトリ階層（このセクションで説明）を、デプロイ可能なアプリケーションを含むディレクトリ階層（前のセクションで説明）から分離することです。この分離を維持することには、以下の利点があります。

• アプリケーションの「実行可能」バージョンが混在していない場合、ソースディレクトリの内容はより簡単に管理、移動、バックアップできます。

• ソースファイルのみを含むディレクトリでは、ソースコード管理がより簡単になります。

• デプロイ階層が分離されている場合、アプリケーションのインストール可能なディストリビューションを構成するファイルの選択がはるかに簡単になります。

ご覧のとおり、ant 開発ツールを使用すると、このようなディレクトリ階層の作成と処理がほとんど手間なく行えます。

アプリケーションのソースコードを格納するために使用される実際のディレクトリおよびファイル階層は、ほとんど自由に設定できます。しかし、以下の構成は非常に一般的に適用可能であることが証明されており、後述するサンプルbuild.xml設定ファイルで想定されています。これらのすべてのコンポーネントは、アプリケーションのトップレベルのプロジェクトソースディレクトリの下に存在します。

• docs/ - 開発チームが使用している任意の形式の、アプリケーションのドキュメント。
  
  
• src/ - サーブレット、Bean、およびアプリケーション固有のその他のJavaクラスを生成するJavaソースファイル。ソースコードがパッケージで構成されている場合（強く推奨）、パッケージ階層はこのディレクトリの下のディレクトリ構造として反映されるべきです。
  
  
• web/ - アプリケーションクライアントからアクセス可能なWebサイトの静的コンテンツ（HTMLページ、JSPページ、JavaScriptファイル、CSSスタイルシートファイル、画像）。このディレクトリはWebアプリケーションのドキュメントルートとなり、ここに存在するサブディレクトリ構造は、それらのファイルにアクセスするために必要なリクエストURIに反映されます。
  
  
• web/WEB-INF/ - アプリケーションに必要な特殊な設定ファイル。これには、Webアプリケーションデプロイメント記述子（web.xml、サーブレット仕様で定義）、作成したカスタムタグライブラリのタグライブラリ記述子、およびWebアプリケーションに含めたいその他のリソースファイルが含まれます。このディレクトリはドキュメントルートのサブディレクトリのように見えますが、サーブレット仕様ではこのディレクトリの内容（または含まれるファイル）をクライアントリクエストに直接提供することを禁じています。したがって、ここには、機密性の高い（データベース接続のユーザー名やパスワードなど）が、アプリケーションが正常に動作するために必要な設定情報を保存するのに適しています。

開発プロセス中に、一時的にさらに2つのディレクトリが作成されます。

• build/ - デフォルトビルド（ant）を実行すると、このディレクトリにはこのアプリケーションのWebアプリケーションアーカイブ内のファイルの正確なイメージが含まれます。Tomcatでは、このように展開されたディレクトリにアプリケーションをデプロイできます。これは、$CATALINA_BASE/webappsディレクトリにコピーするか、「Manager」Webアプリケーションを介してインストールすることで行います。後者のアプローチは開発中に非常に有用であり、以下で説明します。
  
  
• dist/ - ant distターゲットを実行すると、このディレクトリが作成されます。これにより、準備したライセンス情報、ドキュメント、READMEファイルを含む、Webアプリケーションのバイナリ配布物の正確なイメージが作成されます。

これら2つのディレクトリは、開発中に必要に応じて削除および（ゼロから）再作成されるため、ソースコード管理システムにアーカイブすべきではありません。そのため、変更の永続的な記録を保持したい場合は、これらのディレクトリ内のソースファイルを編集すべきではありません。変更は次回のビルド実行時に失われるためです。

前述のとおり、アプリケーションを構成するすべてのソースファイルをソースコード管理システムの管理下に置くことを強くお勧めします。これを選択する場合、ソース階層内のすべてのディレクトリとファイルを登録して保存する必要がありますが、生成されたファイルは対象外です。バイナリ形式のファイル（画像やJARライブラリなど）を登録する場合は、その旨をソースコード管理システムに必ず示してください。

(前のセクションで) 開発プロセスによって作成されるbuild/およびdist/ディレクトリの内容をソースコード管理システムに保存すべきではないと推奨しました。ソースコード管理システムは通常、これらのディレクトリを無視するメカニズムを提供しています（Gitは.gitignoreファイルを使用し、Subversionはsvn:ignoreプロパティを使用し、CVSは.cvsignoreファイルなど）。ソースコード管理システムを次のように無視するように設定する必要があります。

• build
• dist
• build.properties

ここでbuild.propertiesについて言及した理由は、プロセスセクションで説明されます。

ソースコード管理環境の詳細な手順は、このマニュアルの範囲外です。

Javaソースコードファイルのコンパイルとデプロイ階層の作成を管理するために、antツールを使用します。Antは、通常build.xmlと呼ばれるビルドファイルの制御下で動作し、必要な処理ステップを定義します。このファイルはソースコード階層のトップレベルディレクトリに保存され、ソースコード管理システムにチェックインされるべきです。

Makefileと同様に、build.xmlファイルは、オプションの開発活動をサポートするいくつかの「ターゲット」を提供します（関連するJavadocドキュメントの作成、プロジェクトをゼロからビルドできるようにデプロイホームディレクトリを消去、アプリケーションを配布できるようにWebアプリケーションアーカイブファイルの作成など）。適切に構築されたbuild.xmlファイルには、開発者によって使用されることを意図したターゲットと、内部的に使用されるターゲットを記述した内部ドキュメントが含まれます。Antにプロジェクトドキュメントを表示させるには、build.xmlファイルが含まれるディレクトリに移動して、次のように入力します。

ant -projecthelp

手始めに、アプリケーションのプロジェクトソースディレクトリでカスタマイズしてインストールできる基本的なbuild.xmlファイルが提供されています。このファイルには、実行可能なさまざまなターゲットを説明するコメントが含まれています。簡単に言うと、通常以下のターゲットが提供されます。

• clean - このターゲットは、既存のbuildおよびdistディレクトリを削除し、ゼロから再構築できるようにします。これにより、影響を受けるすべてのクラスが再コンパイルされないことによって、実行時に問題を引き起こすようなソースコードの変更を行っていないことを保証できます。
  
  
• compile - このターゲットは、前回のコンパイル以降に変更されたソースコードをコンパイルするために使用されます。結果として生成されるクラスファイルは、Webアプリケーションの構造で要求されるとおり、buildディレクトリのWEB-INF/classesサブディレクトリに作成されます。このコマンドは開発中に頻繁に実行されるため、通常は「デフォルト」ターゲットに設定され、単にantコマンドを実行するだけでそれが実行されるようになっています。
  
  
• all - このターゲットは、cleanターゲットの実行に続いてcompileターゲットを実行するショートカットです。これにより、互換性のない変更を意図せず導入していないことを確実にするために、アプリケーション全体を再コンパイルすることを保証します。
  
  
• javadoc - このターゲットは、このWebアプリケーション内のJavaクラスのJavadoc APIドキュメントを作成します。サンプルのbuild.xmlファイルは、APIドキュメントをアプリケーション配布物ととも含めたいと想定しているため、distディレクトリのサブディレクトリにドキュメントを生成します。通常、コンパイルごとにJavadocsを生成する必要はないため、このターゲットは通常distターゲットの依存関係ですが、compileターゲットの依存関係ではありません。
  
  
• dist - このターゲットは、アプリケーションの配布ディレクトリを作成します。これには、必要なドキュメント、JavaクラスのJavadocs、およびアプリケーションをインストールしたいシステム管理者に配信されるWebアプリケーションアーカイブ（WAR）ファイルが含まれます。このターゲットはdeployターゲットにも依存するため、Webアプリケーションアーカイブにはデプロイ時に含まれたすべての外部依存関係も取り込まれています。

Tomcatを使用してWebアプリケーションを対話的に開発およびテストするために、以下の追加ターゲットが定義されています。

• install - 現在実行中のTomcatに対し、開発中のアプリケーションをすぐに実行およびテストできるように指示します。このアクションではTomcatを再起動する必要はありませんが、次回Tomcatが再起動された後には記憶されません。
  
  
• reload - アプリケーションがインストールされたら、引き続き変更を加え、compileターゲットを使用して再コンパイルできます。TomcatはJSPページへの変更を自動的に認識しますが、サーブレットやJavaBeanクラスへの変更は認識しません。このコマンドは、Tomcatに現在インストールされているアプリケーションを再起動させ、そのような変更が認識されるように指示します。
  
  
• remove - 開発およびテスト活動が完了したら、オプションでTomcatにこのアプリケーションをサービスから削除するよう指示できます。

開発およびテストターゲットを使用するには、次ページで説明する追加の1回限りのセットアップが必要です。