A strong principle of eXtreme Programming (XP) is the continuous integration aspect (see the Continuous Integration article by Martin Fowler). The traditional approach has been to developing the code first, then test it and then integrate it with other appications. The continuous integration principle is to develop code, tests and integrate at the same time, i.e. at any point in time, you have a functioning code along with tests and integrated.
エクストリームプログラミング(XP)の強力な原理は、 継続的インテグレーションの一側面です。 (Martin Fowler 氏の論文 継続的インテグレーションを参照してください。) 古典的な開発のアプローチでは、 まず最初にコーディングし、テストし、他のアプリケーションと統合するというものでした。 継続的インテグレーションの原理では、 コーディング、テスト、統合を同時に行います。 即ち、開発者はどの時点でもテストされ、 統合された、動作するプログラムコードを持っているのです。
In order to be able to do continuous integration, you need to be able to automatically run the build for your application, including passing the unit tests (based on JUnit, Cactus, HttpUnit or others). Ant is the perfect tool for this task.
継続的インテグレーションを行うためには、 (JUnit、Cactus、HttpUnit、他、に基づき) 単体テストを通すことを含めて、 自動的にアプリケーションをビルドできなければなりません。 Ant はこのような作業を行うための完璧なツールなのです。
The benefits of using Ant for running unit tests are as follows :
単体テストを行うために Ant を使う利点は次の通りです :
| メリット/Benefits |
|---|
| Ant is written in Java and thus the same scripts can be used on several systems (Windows and Unix for example). Is is therefore very well suited for building java applications. |
| Ant は Java により記述されているので、 同じスクリプトが複数のシステムで利用可能です。 (例えば、Windows 及び Unix) 従って、Java アプリケーションを開発するのに、最適です。 |
| Ant provides enough built-in and optional tasks to be able to achieve almost any needed build task without needing to use system dependent scripts. |
| Ant では、 システム依存のスクリプトを使わずに、 ビルドで必要な、ほぼ全ての事を達成できるように、 充分な組み込みそしてオプションのタスクが提供されています。 |
| By being able to very quickly rerun unit test you can verify that your tests still pass when you modify some part of your code ( regression testing) |
| 単体テストを迅速に再実行できるので、 コードを一部変更した時でも、テストに合格するか確認できます。(回帰テスト) |
| As it is automated, it fits well in the continuous integration principle and your tests can thus be ran automatically and continously |
| 自動化されているので、継続的インテグレーションの原理にとてもよくマッチし、 テストを自動的に、かつ、継続的に実行できます。 |
The sample Ant build file described below is taken from the Cactus Sample for Servlet API 2.2 project.
下に示すAnt のサンプルビルドファイルは Servlet API 2.2 用 Cactus サンプル のプロジェクトにあるものです。
Create the following directories :
次のディレクトリを作成します :
| Directory name | Content of the directory |
|---|---|
build
|
The Ant build file and some other ancillary files (properties file, ...) |
conf
|
Configuration files for the project. These are the configuration
files that will not be put into the runtime jar. They
are configuration file that need to be visible and modifyable
by a user of the project. If they were bundled in the jar they
would be hard to modify. On the other hand, we don't want a
proliferation of configuration files, so all technical
configuration files (messages to display for errors, ...)
should be put in the src directory in correct java
packages.
|
conf/test
|
Configuration files needed for testing the project only. |
docs
|
Project documentation. |
docs/skins
|
Documentation skin for Stylebook (if using Stylebook). |
docs/xdocs
|
Documentation files (XML files) for Stylebook (if using Stylebook). |
src
|
The project sources : java files + java test files + properties files + test properties files + other files for runtime or test (XML files, ...). Note that all test files should begin by 'Test' or 'test' in order to easily separate them from other files so that in an Ant target we'll be able to include only the runtime files. |
web
|
The project web files : HTML, JSP, ... (if any) |
| ディレクトリ名 | ディレクトリの内容 |
|---|---|
build
|
Antビルドファイル、および補助ファイル(プロパティファイル、など) |
conf
|
プロジェクトの設定ファイル。
これらは、ランタイムの jar
ファイルに置かれない設定ファイルです。
これらは、プロジェクトのユーザーにより、
参照および編集が必要な設定ファイルです。
もし、これが jar ファイルの中に置かれていたなら、
変更は難しかったでしょう。
一方で、
設定ファイルを増殖させたくはないので、
全ての技術的な設定ファイル
(エラーで表示されるメッセージなど、、)は
正しい java パッケージのsrc
ディレクトリに置くべきです。
|
conf/test
|
プロジェクトのテストにのみ必要な設定ファイル |
docs
|
プロジェクトのドキュメント |
docs/skins
|
(stylebookを使う場合)stylebook用のドキュメントテンプレート |
docs/xdocs
|
(stylebookを使う場合)stylebook用のドキュメントファイル(XMLファイル) |
src
|
プロジェクトのソース : java ファイル + java テストファイル + プロパティファイル + テストプロパティファイル + ランタイムやテスト用の他のファイル(XMLファイル等)。 Ant ターゲットにおいてランタイムファイルのみを含められるよう、 簡単にこれらを他のファイルと区別するために、 全てのテストファイル名は 'Test' あるいは 'test' で始らなくてはなりません。 |
web
|
(もしあれば)プロジェクトのウェブファイル : HTML,JSP... |
out directory will be created by the Ant build. All
build-generated files will be put in that directory (compiled classes,
generated javadoc documentation, test configuration files for running
an application server, ...).
outディレクトリはAntのビルドにより生成されます。
ビルドが生成した全てのファイルはこのディレクトリに置かれます。
(コンパイルされたクラス、生成された javadoc ドキュメント,
アプリケーションサーバーを実行するためのテスト設定ファイル、等)
lib directory because it is always
better not to include dependent jars in your project whenever
possible for the following reasons : better continuous integration
with other libraries (meaning they also evolve and you should test
as much as possible with the latest version to discover potential
problems early, more lightweight downloads, less jar proliferation
(you'll end up with tens of the same jars otherwise), more version
control and integration checks (if your project uses 2 external
libraries that need another third library but not in the same version
you are in trouble !), ...
libディレクトリを使いたくありません。
なぜなら、可能ならば次に示す理由により、
プロジェクトに依存関係のある
jar ファイルをインクルードしない方が必ず良いからです :
それは、
他のライブラリとの継続的インテグレーションがやりやすいという事です。
(これにより、進化し、
問題発生の可能性を早く見つけるために、
最新のバージョンでできる限り多くテストし、
ダウンロードを軽量化し、
jar ファイルの増殖を防ぎ、
(さもないと、同じ 10 個の jar を持つことになります。)
バージョンコントロールおよび結合テストが数多くできます。
(もし、同じバージョンでないような、
別の第3のライブラリを必要とする
2 つの外部ライブラリをプロジェクトで使っているとしたら、
トラブルに巻き込まれるでしょう)、、、
Define the following targets in your build.xml.
build.xmlにおいて次のターゲットを定義してください
| Target name | Description | Type |
|---|---|---|
init |
Defines token filters, timestamp, display some information on screen, ... | Internal |
usage |
Display usage information about the targets. | External |
prepare |
Set up the output directory where build generated files will be
put and copy the java sources to this output directory,
replacing tokens with the values defined in the init
target.
|
Internal |
compile |
Compile the java sources and put the result in the output
directory. All copies non java source files such as
.properties files, XML configuration files, ...
|
Internal |
source |
Generate a zipped file containing the full sources of the project (i.e. the whole directory structure, excluding any build generated files). | External |
javadoc |
Generates the javadoc of the project. This javadoc will be part
of the project documentation, as generated by the doc
target.
|
Internal |
doc |
Generates the full project documentation : javadoc + README files + documentation web site (using Stylebook for example). | External |
clean |
Remove any build generated files. In particular, delete the output directory. | External |
jarwarear, ...
|
Generate the project runtime. If the project is a framework, it is usually a jar. If the project is a web application, it is usually a war file. If the project is an EJB application, it is usually either one or several jars or an ear file. Etc ... | External |
tests_XXX |
Run the Cactus unit tests. | External |
| ターゲット名 | 説明 | 種類 |
|---|---|---|
init |
トークンフィルター、タイムスタンプを定義し、 スクリーン上に何らかの情報を表示します、、、 | 内部 |
usage |
ターゲットに関する使用法の情報を表示します | 外部 |
prepare |
出力先ディレクトリを設定します。
このディレクトリに、
ビルドにより生成されたファイルが置かれ、
initターゲットにおいて定義された値により、
トークンを置換して、この出力ディレクトリに
java のソースをコピーします。
|
内部 |
compile |
java ソースをコンパイルし、結果を出力先ディレクトリに置きます。
.properties ファイルや、
XML 設定ファイルといった全てのファイルをコピーします。
|
内部 |
source |
プロジェクトの全てのソースを含んだ ZIP アーカイブを生成します。 (即ち、ビルドにより生成されたファイルを除いた、 ディレクトリ構造全体です。) | 外部 |
javadoc |
プロジェクトの javadoc を生成します。
docターゲットに生成されたように、
この javadoc はプロジェクトドキュメントの一部です。
|
内部 |
doc |
プロジェクトドキュメント全体を生成します : javadoc + README ファイル + (例えば stylebook を使った)ウェブサイトのドキュメント | 外部 |
clean |
ビルドにより生成されたファイルを全て削除します。 特に output ディレクトリを削除します。 | 外部 |
jarwarear, ...
|
プロジェクトのランタイムを生成します。 プロジェクトがフレームワークの場合、通常 jar が、 ウェブアプリケーションの場合、通常 war が、 EJB アプリケーションの場合、通常、 一つかそれ以上の jar か、あるいは、 一つの ear ファイルが生成されます。 | 外部 |
tests_XXX |
Cactus 単体テストを実行します | 外部 |
You build.xml file being in located in
build/ you should set the project tag
basedir
attribute to '..' so that all other paths are relative
to your project root directory. Indeed, the batch file (shell script)
that was used to bootstrap Ant is located in
<root>/build, so '..' is the root
directory.
他の全てのパスがプロジェクトのルートディレクトリから相対的になるように、
build/ディレクトリにあるbuild.xmlファイルにおいて、
projectタグ中のbasedir属性を
'..' に設定しなければなりません。
実際に、
'..' がルートディレクトリなので、
Ant を起動するのに使われるバッチファイル(シェルスクリプト)は
<root>/build にあります。
Example :
例 :
You should define as properties all values that can be factorized and which are used often in your build file such as source locations, output locations, external jar locations and names, ... You can also define useful file patterns there (see the sample below).
ソースの場所、出力先、外部 jar の位置や名前など、 要素に分解できて、ビルドファイル中で頻繁に使われる値はプロパティとして定義すべきです。 そこでは便利なファイルパターンも定義できます。 (下を参照してください)
A good principle is to defined any properties that depend on your
environment (such as external jar locations) in a file (let's call
it build.properties located either where
build.xml is located or in your home directory. The
properties defined in this file will be loaded by
build.xml using the following code :
プロパティを定義する良い原則は、
(外部 jar の場所など)自分の環境に依存するどんなプロパティでも、
一つのファイル中に定義することです。
(build.xml ファイルがある場所や、
ホームディレクトリにあったとしても、
これをbuild.propertiesと呼ぶことにします。)
このファイルで定義されたプロパティは次のような文を使って、
build.xmlに読み込まれます。
Here are our properties initializations :
以下にプロパティの初期化を示します :
Useful for initializing a timestamp (DSTAMP, TODAY, TSTAMP), defining token filters, printing some information messages, registering custom Ant tasks, ...
タイムスタンプ(DSTAMP,TODAY,TSTAMP)を初期化したり、 トークンフィルターを定義したり、メッセージ情報を出力したり、 カスタム Ant タスクを登録したり、等に便利です。
Display a usage message.
使用法メッセージの表示
This target is needed for both compiling and generating the javadoc.
It copies all the source files from their src/ directory
to the out directory, replacing tokens in the source
code (replacing the 1.3 by the version number
for example).
このターゲットはコンパイルおよび javadoc の生成の両方で必要です。
ソースコード中のトークンを置換しながら、
src/ディレクトリの全てのソースファイルを
outディレクトリにコピーします。
(例えば、1.3 をバージョン番号で置き換えます。)
The compile target simply compiles the java files into
.class files and also copies the support files that are
in src/ to the directory where the class file have been
generated.
compile ターゲットは単に、
java ファイルを .class ファイルにコンパイルし、さらに、
src/ にあるサポートファイルを、
クラスファイルが生成されたディレクトリにコピーします。
Zip up the sources for distribution.
ディストリビューションのためのソースのZIPアーカイブの作成
Generate the project's javadoc.
プロジェクトの javadoc の生成
Generate the project's documentation. It includes the javadoc, additional README files (if any) and the documentation web site (built using Stylebook for example, as shown in the example below).
プロジェクトのドキュメントの生成。 これには、javadoc や、 (あれば)付加的な README ファイルや、 ウェブサイト用のドキュメント (例えば、下の例のように stylebook を使って生成されます。) が含まれます。
Example not using Stylebook :
stylebook を使わない例 :
Example using Stylebook (from the Cactus build file itself) :
stylebook を使った例(Cactus ビルドファイル自身より) :
Removes all build generated files.
ビルドにより生成された全ファイルの削除
This target is useful if your project is a framework for example and
you need to deliver a jar file. We also include a manifest file
in the jar, with version information. We copy the manifest to the
output directory in order to replace the 1.3
token with it's value.
このターゲットは、例えば、自分のプロジェクトが、
フレームワークで 'jar' ファイルで配布する必要があるときに便利です。
jar ファイルには、バージョン情報を持ったマニフェストファイルも入れます。
1.3 トークンを、その値に置換するために、
マニフェストファイルを出力ディレクトリにコピーします。
Example (from the Cactus build file) :
例 (Cactus ビルドファイルより) :
This target is useful if you're building a web application.
We also include a manifest file in the war, with version
information. We copy the manifest to the output directory in order
to replace the 1.3 token with it's value.
このターゲットはウェブアプリケーションを構築する時に便利です。
バージョン情報を持ったマニフェストファイルも war に入れます。
1.3 トークンをその値に置換するために、
マニフェストを出力ディレクトリにコピーします。
Example (from the Cactus sample) :
例 (Cactus のサンプルより) :
The tests_XXX target is in charge of running the
Cactus unit tests. It must prepare the test environment for a
given servlet engine and package the tests, start that servlet
engine, run the tests by starting the JUnit runner and stop the
servlet engine.
tests_XXX ターゲットは、
Cactus 単体テストの実行を担当しています。
与えられたサーブレットエンジンのテスト環境の準備をし、
テストをパッケージ化し、サーブレットエンジンを実行し、
JUnit runner を起動することによりテストを実行し、
サーブレットエンジンを終了します。
See the Using Cactus with Ant tutorial for details on to do this.
これを行うための詳細については、 Ant での Cactus の利用 のチュートリアルを見てください。