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

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はフローを記述するのには向かず、例え書けたとしても、人間が読みやすいものではありません。
 

まとめ

   今回はビルドツールAntと、EclipseのAnt支援機能について紹介しまし た。Antは、既に広く広まっている安定した便利なツールで、Eclipseともよく統合されています。ちょっとした処理、あるいはプロジェクトの中心ビ ルドツールとして、使わずにはいられないツールです。