前 | トップ | 次 |
作成 設定 開発 ビルド テスト 配備 |
アプリケーションの開発は様々な形態を取ることがありますが、このマニュアルではTomcatを使用したWebアプリケーションを作る際の極めて一般的な手続きを提案します。 コードの開発者であるあなたが実行するであろうコマンドやタスクを、以下の節では強調表示しています。 このアプローチは、適切なソースコード管理システムを持ち、誰がどの部分をいつ開発するかさえ決めていれば、複数のプログラマで作業する際にも適用できます。
以下のタスクに関する記述では、CVS をソースコード管理として使用していて、すでに適切な CVS レポジトリにアクセスできることを前提にしています。 これらの説明についてはこのマニュアルの範疇ではありません。 CVS 以外のソースコード管理環境を使用している場合には、そのシステムに対応するコマンドを実行してください。
最初のステップでは、新規のプロジェクトソースディレクトリを作成し、
build.xml
と使用する予定のbuildスクリプトをカスタマイズします。
ディレクトリの構造については、4節で説明しています。
また、sampleアプリケーションを参考にしても良いでしょう。
プロジェクトソースディレクトリを作り、CVS レポジトリの中にそれを定義しましょう。
これは以下のような一連のコマンドで行うことができます。
{プロジェクト}
は CVS レポジトリの下のプロジェクトが格納される名前です。
また {ユーザ名} はあなたのログインユーザ名です。
cd {私のホームディレクトリ} mkdir myapp <-- "プロジェクトソースディレクトリ" とする cd myapp mkdir etc mkdir lib mkdir src mkdir web cvs import -m "Initial Project Creation" {プロジェクト} \ {ユーザ名} start
CVS 内に正常に作成されたかどうかは、この新規プロジェクトをチェックアウトしてみることで確認できます。
cd .. mv myapp myapp.bu cvs checkout {プロジェクト}
次に、このプロジェクトの開発に使用するbuild.xml
と
build
またはbuild.bat
を作成して、チェックインする必要があります。
build.xml
作成する時には、
基本的なbuild.xmlファイルを元にしても良いし、白紙の状態から書いても良いでしょう。
cd {私のホームディレクトリ} cd myapp emacs build.xml <-- お好みのエディタでどうぞ :-) cvs add build.xml emacs build <-- Windows 上では build.bat chmod +x build <-- Unix 上で実行可能にします。 cvs add build <-- Windows 上では build.bat cvs commit
ここまでにbuild.xml
ファイルと対応するbuildスクリプトに対して編集した内容は、あなたの開発ディレクトリにしか影響しません。
コミットすれば、他の開発者にも変更が見えるようになります。
さて、最初のWebアプリケーション配備記述子をつくりましょう。
web.xml
作成の際には、基本的なweb.xmlファイルを元にしても良いですし、白紙から書いても良いでしょう。
cd {私のホームディレクトリ} cd myapp/etc <-- WEB-INF のある場所 emacs web.xml cvs add web.xml cvs commit
Tomcat にアプリケーションを認識させるためには、
3.4節に書かれている方法で統合を行ってあげる必要があります。
どの方法でも構いません。
今回の場合には、配備のホームを $TOMCAT_HOME/webapps
以下の適当なディレクトリとしているので、最初のアプローチ(ディレクトリ階層を配備する方法)を使うものとして話を進めます。
開発者が複数の場合には、各々が独立した TOMCAT_HOME (ここは Tomcat を開始、停止する場所でもあります) を持てるように、Tomcat をそれぞれにインストールするのがもっとも簡単でしょう。
編集/ビルド/テスト は、開発・保守の間、もっとも一般的な行動になるでしょう。 以下の一般的な原則を当てはめることができます。 4節で述べられているように、新規に作成した ソースファイルは、プロジェクトソースディレクトリ以下の適切なサブディレクトリに配備しなければなりません。
他の開発者が行った変更を自分の開発ディレクトリに反映させようと思ったら、 CVS にいつでもそうさせることができます。
cd {私のホームディレクトリ} cd myapp cvs update -d <-- -d は必要なディレクトリがあれば作成する ためのオプションです。
新規にファイルを作成するためには、適切なディレクトリに移動して、ファイルを作成し、それを CVS に登録します。 ファイルの内容が満足いくものになったら(ビルドし、テストが成功した後に)、レポジトリに新規のファイルをコミットしてください。 例として、新規の JSP ページを作成する場合を以下に挙げます。
cd {私のホームディレクトリ} cd myapp/web <-- ドキュメントルート emacs mypage.jsp cvs add mypage.jsp ... アプリケーションのビルドとテスト ... cvs commit
パッケージ内で定義されたJavaのソースコードは(src/サブディレクトリ
以下の)パッケージ名と同じ階層に整理されねばなりません。
たとえば、com.mycompany.mypackage.MyClass.java
と名付けられた
Java ソースコードは、プロジェクトソースディレクトリ以下の
src/com/mycompany/mypackage/MyClass.java
に置かねばなりません。
新規のサブディレクトリを作成した際にも、忘れずに CVS レポジトリに登録
してください。
すでに存在しているソースファイルを編集する場合には、一般的に、単に編集と テストを始め、そしてすべてがうまくいったら変更をコミットします。 もしかすると、変更しようとしているファイルに対する "チェックアウト" や "ロック"を要求するように CVS が設定されているかもしれませんが、普通はそのように設定しません。
アプリケーションをコンパイルする準備が整ったら、以下のコマンドを実行してください (普通は、最後のコマンドだけを打てば良いように、プロジェクトソースディレクトリを指定しているシェルウィンドウを開きっぱなしにしておきたいと思うことでしょう)。
cd {私のホームディレクトリ} cd myapp <-- 普通、この場所で Window を開きっぱなしに しておきます。 build <-- (Windows) デフォルトでは "build compile" と同じ。 ./build.sh <-- (Unix) デフォルトでは "build compile" と同じ。
Antツールは、新規に作成したり、更新したJava コードをコンパイルするために役に立ちます。 もしこれが "build clean" した後の最初のコンパイルであれば、すべてのものが再度コンパイルされます。
すべてのアプリケーションを強制的に再コンパイルしたい場合には、 代わりに以下のようにしてください。
cd {私のホームディレクトリ} cd myapp build all <-- (Windows) ./build.sh all <-- (Unix)
変更をチェックインする前に、Javac の構文チェックに引っかからないような 小さなバグを埋め込んでいないことを確認することは、とても良いことです。
アプリケーションをテストするために、Tomcatを用いて実行したいと思うことがあります。 ここでは、上に記述した方法ですでにアプリケーションの統合を行っているものとして話を進めます。 この場合には、後は非常に簡単です。 Unix 環境では、単に以下のように実行します。
$TOMCAT_HOME/bin/startup.sh
また、Windows 環境では、以下のように実行します。
%TOMCAT_HOME%\bin\startup
このコマンドは Tomcat をバックグラウンドプロセスとして起動します。 以下の URL を、Webブラウザでアプリケーションのホームページを開いて 見てください。("/myapp" はあなたが割り当てたコンテキストパスです。)
http://localhost:8080/myapp
アプリケーションが正しい動作をしているかどうかを確認することができます。 修正が必要なことがわかった時には、次のように修正してください。
build
スクリプトを再度実行してください。
更新されたページがコピーされると、そのページに次のアクセスがあった時に
Tomcat は更新されたと認識し、そのページは自動的に再度コンパイルされます。
build
スクリプトを再度実行します。
更新された Java クラスは再度コンパイルされます。autoreload
が選択されていた場合には、次にこのクラスが参照されたときに Tomcat は
更新されたと認識し、自動的にアプリケーションのunload と reload が
行われます。そうでない場合は、手動で Tomcat を停止、再起動する必要が
あります。
servlet と JSP ページのデバッガの使用方法については、現在はこのマニュアル の範疇ではありません。しかし、これらの手続きについての解説を追加することが求められています。
テストを終えた後に、ソースコードレポジトリに変更をコミットすることを 忘れずないでください!
新しい機能を追加して、全てのテストを終えたら(もちろんですね :-)、 Webアプリケーションの製品版サーバに配備することのできる配布バージョン の作成に取りかかります。
build all
コマンドを
実行して、最新の状態ですべてを最初から再ビルドします。
build dist
コマンドを実行して配布可能な Webアプリケーションアーカイブ (WAR)ファイルを
作成します。
[訳注: これは河内崇が翻訳しました。 日本語訳に対するコメントは、jajakarta-report@nekoyanagi.com宛に送って下さい。]