ソースコードの構成

目次

ディレクトリ構造

以下の説明では、変数名 `$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ファイル（またはその他の資源）を必要とする場合はどうすればよいでしょうか？一般的な例としては、動作するためにWebアプリケーションにJDBCドライバを含める必要があることが挙げられます。

開発者によってはこの問題に対するアプローチが異なります。一部の開発者は、依存するJARファイルのコピーを、それらのJARファイルを使用するすべてのアプリケーションのソースコード管理アーカイブにチェックインすることを推奨します。ただし、多くのアプリケーションで同じJARを使用する場合、特にそのJARファイルの異なるバージョンにアップグレードする必要がある場合、これは重大な管理上の問題を引き起こす可能性があります。

したがって、このマニュアルでは、依存するパッケージのコピーをアプリケーションのソースコード管理アーカイブに格納**しない**ことをお勧めします。代わりに、外部依存関係は、アプリケーションの**ビルド**プロセスの一部として統合する必要があります。このようにすることで、開発システム管理者がそれらをインストールした場所からJARファイルの適切なバージョンを常に取得でき、依存するJARファイルのバージョンが変更されるたびにアプリケーションを更新する必要がなくなります。

サンプルのAnt `build.xml`ファイルでは、これらのファイルが変更されたときに `build.xml` を変更する必要なく、コピーするファイルの場所を構成できる *ビルドプロパティ* を定義する方法を示します。特定の開発者によって使用されるビルドプロパティは、アプリケーションごとにカスタマイズしたり、開発者のホームディレクトリに格納されている「標準」ビルドプロパティにデフォルト設定したりできます。

多くの場合、開発システム管理者は既に必要なJARファイルをTomcatの `lib` ディレクトリにインストールしています。これを行っている場合は、何もする必要はありません。サンプルの `build.xml` ファイルは、これらのファイルを含むコンパイルクラスパスを自動的に構築します。

ソースコード管理

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

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

  • build
  • dist
  • build.properties

`build.properties` をここで説明する理由は、`プロセス` セクションで説明します。

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

BUILD.XML 構成ファイル

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` ディレクトリのサブディレクトリにドキュメントが生成されます。通常、すべてのコンパイルでJavadocを生成する必要はないため、このターゲットは通常、`compile` ターゲットではなく `dist` ターゲットの依存関係になります。

  • dist - このターゲットは、必要なドキュメント、JavaクラスのJavadoc、システム管理者がアプリケーションをインストールするために使用するWebアプリケーションアーカイブ（WAR）ファイルなど、アプリケーションの配布ディレクトリを作成します。このターゲットはdeployターゲットにも依存するため、Webアプリケーションアーカイブには、展開時に含まれていた外部依存関係も含まれています。

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

  • install - 現在実行中のTomcatに、開発中のアプリケーションをすぐに実行およびテストできるように指示します。このアクションではTomcatを再起動する必要はありませんが、次回Tomcatを再起動した後は保持されません。

  • reload - アプリケーションがインストールされたら、compileターゲットを使用して変更を継続してコンパイルできます。TomcatはJSPページへの変更を自動的に認識しますが、サーブレットまたはJavaBeanクラスへの変更は認識しません。このコマンドは、Tomcatに現在インストールされているアプリケーションを再起動して、そのような変更を認識させます。

  • remove - 開発とテストの活動が完了したら、必要に応じてTomcatにこのアプリケーションをサービスから削除するように指示できます。

開発およびテストターゲットを使用するには、次のページに記載されている追加の一時的な設定が必要です。