Eclipse3ではじめるJava Webアプリケーション開発第11回

EclipseユーザにとってのAntの用途

Antの用途について、もう少し考えてみましょう。

Antは、コンパイル、テスト、パッケージング、デプロイといった一連のビルド処理を記述することができます。以前は、コンパイルをコマンドラインやバッチファイルで行うよりAntで行った方が便利だという利点がありました。しかし、高機能なIDEが広まってきたことで、この部分にAntを利用する意味は以前ほどはありません。EclipseユーザにとってのAntの用途は、以下のものでしょう。

一連のビルド処理
Eclipseが提供していない機能
標準のビルド

一連のビルド処理

   一連の処理をコマンド一発で実行するのにAntはよく利用されます（バッチファイル的な使われ方）。一部のファイルを修正して実行可能なモジュールを作成するのに、複数の手順を手動で行うのは手間ですし、間違いも多いので、一連のビルド処理にはAntのようなビルドツールを利用します。

   さらに、Antはマルチプラットホームで動作するので、誰がどの環境で実行しても（せいぜい出力パスなどを切り替えるぐらいの設定で）同じ結果を得ることができます。

   また、デイリービルドを行うツールとしてAntが利用されることも多いです。毎晩、SCM（CVSなどのソースコード管理システム）からファイルを取得して、コンパイル、パッケージング、テスト、デプロイ、レポート作成などを作成し、朝にはテスト結果と最新のモジュールが利用できる状態にしておくことができます。

Eclipseが提供していない機能

Eclipseはさまざまな機能を提供しており、またプラグインを組み込むことでさまざまな処理を行うことができます。しかし、プラグインが提供していない機能や、プラグインの利用では使い勝手が悪い場合は、Antを利用することもしばしばあります。

例えばプロジェクト環境に応じたパッケージングやデプロイ、ネイティブモジュールのビルドなどにAntを利用することができます。また、AntはEclipseのビルドプロセスに組み込むこともできます。

標準のビルド

プロジェクトによっては、開発者の環境がまちまちのことがあります。クライアント開発環境を統一するか、個人にまかせるかは、開発環境の差異による問題を防ぐか、使いなれたツールで個々人の生産性を高めるかのトレードオフです。開発環境が異なる場合、標準のビルドをAntと決めておくことで、誰かの環境ではテストが通らない、あるいはビルドのステップごとに、誰かの環境で何かをしないと進まないといった問題を解決することができます。

Antのデメリット

もしAntのデメリットを挙げるとすれば次のことが考えられます。

巨大なプロジェクトでは複雑になる

既存のタスクを利用して、簡単にビルドが書けるといっても、複雑なビルド処理を記述していくとビルドファイルが大きくなってきます。複数のサブプロジェクトを含むような巨大なプロジェクトでは、ビルドも巨大になってしまいます。ソフトウェア開発一般でそうであるように、大きなシステムであまり考えなしに進めてしまうと、メンテナンス不能になってしまいます。

Javaにコーディング標準があるように、ビルドファイルでも、サブプロジェクト間で共通のビルド記述ルールを決めておくとよいでしょう。また、 Ant 1.6からのimportやmacrodefなどを利用して、ビルド中でも共通処理は一箇所に書いておいた方がよいでしょう。

XMLによる宣言的な記述では処理が書きづらいかもしれない

AntのビルドはXMLファイルで宣言的に記述します。これは、タスクの作者とビルドファイルの作者を明確に分け、タスクの再利用を促すよいしくみです。反面、条件分岐やループといった、ちょっとしたフローを記述したいときに融通がききません。そもそもXMLはフローを記述するのには向かず、例え書けたとしても、人間が読みやすいものではありません。