XPのインプリメントに必要なツールについては、習熟に多少時間を要するという、ありがたくない一面があります。ありがたい点としては、最初の段階で必要となるツールが、あきれるほど少ないということがあります。たくさんのドキュメント・オーサリング・ツールや設計ツールがなくても、立派なソフトウェアを作成することができます。結局、必要なのは、技術以外のものの供給、若干のソフトウェア、そして数人の熱心なチーム・メンバーなのです。XPとは、そもそも、うまくいく可能性のあることを、最も単純に行うためのあらゆる事柄を指しているということを思い出してください。このことは、設計、コード、プロセス、そしてもちろん ツールに当てはまります。
私は、ソフトウェアの作成とプロジェクトの管理に携わって10年になります。その間、管理やコーディングのためにかなりの数のツールを使用してきました。そのようなことをしておきながら、あえて言わせていただきますが、皆さんはツールに頼りすぎています。ツールは、決められた用途に合わせて使うものであって、スキルや経験に代わるものではありません。
読者やそのチームには、まず、習熟に時間がかからず、多くの能力と機能を備えた、比較的単純なツールから使い始めることを (そしておそらく、使い続けることも) お勧めします。読者がJava言語を使用しているものと想定し (そもそも、これはJavaテクノロジー・ゾーンの記事なのですから)、プロジェクトで使用する以下のようなツールについて考えてみてください。
- チームにとって使いやすい、基本的な開発環境としての Eclipse
- 愛用の ソース・コード制御ツール (私は、Eclipseを使用するときにはCVS使うようにしてきました)
- プログラマー・テスト用の JUnit (おそらく、カスタマー・テスト用のエンジンとしても使用可能です)
- Webアプリケーションをテストするための HttpUnit
- 日常的に アプリケーションを作成するための Ant
- まだ作成していないコンポーネントを、そのコンポーネントの存在を必要とするテストを行って探り出すための Shams
この記事では、Eclipse、JUnit、およびAntの効果的な使用方法に焦点を当てます。(HttpUnitについては、この後の記事で取り上げます。また、Shamsについては、前回の「 テスト主導型プログラミング 」で説明しました。)
私は、これまでのプログラマー生活で、いくつかのIDEを使用してきました。最初にVisualAge for Java (VAJ) を使い始めたときには、習得にひどく時間がかかるような気がしたのですが、2~3週間もすると、これまでにVAJなしに Javaソフトウェアを書いた人はいるのだろうかと思うようになりました。VAJは、それまで私が使用したIDEの中で、最もすばらしいものでした。しかし、Eclipseはそれよりもすぐれています。しかも、フリーウェア なのです (本当です)。
Eclipseは、チームで使用できる本当の意味で統合された開発環境があってしかるべきであるという、単純な前提に基づいて作られています。このアプリケーション全体は、Java言語で開発を行うためにJava言語で書かれています。リッチで十分にファクター化された (well-factored) コードを見てみたいという人にとって、Eclipseのソースは格好の例です。このアプリケーションは、実際には、プラグイン・アーキテクチャーを基にした、アプリケーションを構築するためのフレームワークです。Eclipseのほとんどすべては、Java言語開発のサポートも含め、プラグインです。コアとなるプラットフォームがあって、ほかのすべてのものがそれにプラグインされるようになっているのです。入門編の記事はEclipseサイトおよびこのdeveloperWorks にたくさんありますので ( 参考文献 を参照)、この記事ではこのツールの使い方の概要だけを述べることにします。
インストールは簡単です。 Eclipseダウンロード・ページ に行って、ミラー・サイトを選び、最新の安定版 (Stable) ビルドまたは最新リリース (2.1) をダウンロードしてください。Eclipseをアップグレードする新規リリースが出るまで待とうなどとは考えないでください。Eclipseチームの人々は文字どおりのテスト第一主義者であり、あらゆる種類のテストを用意してくれていますので、調べてみれば、安定版ビルドは十分に安定していることが分かります。
リリースをダウンロードしてから、以下のステップを行ってインストールし、実行してください (読者がなんらかのWindows系OSを使用していることを想定しています)。
- JDK 1.4をインストールします (まだダウンロードしていない場合のダウンロード方法については、 参考文献 を参照してください)。
- Eclipse のZIPファイルをC:\eclipseに解凍します。
-
ハード・ディスク上に
C:\EclipseWorkspacesという名前の別のディレクトリーを作成します。 -
「スタート」メニューに、
C:\eclipseで開始されるC:\eclipse\eclipse.exe -data C:\EclipseWorkspaces\<your workspace name>へのショートカットを作成します。 -
その新規ショートカットをダブルクリックします。
C:\EclipseWorkspaces内にワークスペース用のサブディレクトリーが作成されます。
初めてEclipseを始動したときには、図1のような画面が表示されます。
図1. Eclipseのウェルカム画面
このウェルカム画面はEclipseワークスペースのResource (リソース) パースペクティブ の一部です。このパースペクティブでは、ワークスペース内のすべてのファイルのビューが表示されます。ファイルのリストは、「Navigator」ビューの左上隅に表示されます。Eclipseは完全にカスタマイズ可能になっていますので、ビューは任意の位置に移動することができます。さしあたり、ビューはそのままにしておいて、Java Browsingパースペクティブに進んでください。「 Window >Open Perspective 」と選択することにより、どのパースペクティブが使用可能なのかを調べることができます。「Java Browsing」パースペクティブを選択してください。図2にこのパースペクティブを示してあります。
図2. 「Java Browsing」パースペクティブ
「Java Browsing」パースペクティブには、上部に4つのビューがあり、下部にエディターがあります。4つのビューには、左から右への順にProjects、Packages、Types、およびMembersが示されます。Packages、Types、およびMembersはすべて、読者におなじみのJava言語構造体です。Projectsは、Javaパッケージ用のEclipseメタ・コンテナーです。開発の大半はこのパースペクティブで行われますが、Resourceパースペクティブも、リソース・ファイルおよびクラス・ファイル以外のファイルを操作するのに便利です。
開発を開始するには、以下のステップに従って
Sample
というJavaプロジェクトを作成してください。
- 「 Window >Preferences >Java >New Project 」とクリックします。
- 「 Folders 」ラジオ・ボタンをクリックし、「 OK 」をクリックします。
- 「 File >New >Project 」とクリックします。
- 「 Java Project 」を選択し、「 Next 」をクリックします。
- プロジェクト名として Sample と入力し、「 Finish 」をクリックします。
「Projects」ビューに
Sample
プロジェクトが表示されるはずです。ここで、ツールバーにある「
New Java Package
」ボタンをクリックして、
com.sample
というパッケージを作成します。そのパッケージを選択してください。これで、最初のJavaクラスを作成して、EclipseがXP開発の流れをどのように促進するのかを確認できるようになります。
過去10年間の私のソフトウェア開発の経歴に最も大きな影響を与えたものはXPでした。プログラマーの私にとって、最も衝撃的なプラクティスは (XPもその他のプログラミングも含め)、コードを書く前に テストを書くということでした。 先月 述べたように、テストにパスするのに十分な程度のコードを書くようにすると、コードが簡潔な状態に維持され、当面の作業に専念することができます。先月、JUnitを使用する手順のいくつかについて述べましたが、ここでもう少し詳しく説明することにします。
JUnitはEclipseに付属していますので、ダウンロードする必要はありません。Eclipseを使用していない場合には、JUnitをダウンロードしてください ( 参考文献 を参照)。JUnitを使用するためには、最初にJUnit JARをプロジェクトのビルド・パスに含め、テスト・クラスを作成してください。JUnitをプロジェクトのビルド・パスに含めるには、以下のステップに従ってください。
-
Sampleプロジェクトを右マウス・ボタン・クリックし、コンテキスト・メニューの下部で「 Properties 」を選択してください。 - 「 Java Build Path 」を選択します。
- 「 Libraries 」タブを選択します。
- 「 Add Variable 」ボタンをクリックします。
- 「 New 」ボタンをクリックし、変数名として JUNIT_liB と入力します。
-
その変数を編集して、
C:\eclipse\plugins\org.junit_3.8.1内のファイルを指すようにします (JUnitはEclipseのプラグインです)。 - 「Sample」プロジェクトから「 src 」フォルダーを選択します。
これで、ビルド・パスにJUnitが含まれるようになりました。外部JARをこのパスに直接追加することも可能ですが、変数を使用したほうが、別のマシンでワークスペースをセットアップしやすくなります (この変数は、マシン特定の位置を指すことのできるメタ名です)。テスト・クラスを作成するには、次のステップに従ってください。
- ツールバーの「 New Java Class 」ボタンの右にあるドロップダウン矢印をクリックし、「 TestCase 」を選択します。
- テスト名として「 TC_Account 」と入力します。
- 「 setUp() 」チェック・ボックスおよび「 tearDown() 」チェック・ボックスを選択します。
- 「 Finish 」をクリックします。
これにより、図3に示すような画面が表示されるはずです。
図3. テスト・ケースのオープン
「Types」ビューに
TC_Account
クラスがリストされ、そのクラスのメソッドが「Members」ビューに表示されます。
TC_Account
クラスでエディターがオープンし、生成された多くのコードおよびコメントが表示されます。私は、生成されたすべてのコメントを表示されないようにプリファレンスを設定するようにしています。これは、「
Window >Preferences >Java >Code Generation
」を選択することによって設定できます。
Account
クラスは何を行うのでしょうか?まず、口座に金額を追加できるようにします。そのためには、次のようなメソッドが必要です。
public void deposit(int amount) |
Account
で
deposit
メソッドをテストするためのメソッドを
TestCase
に追加します。テスト・クラスはリスト1のようになるはずです。
リスト1. JUnitテスト
package com.sample;
import junit.framework.TestCase;
public class TC_Account extends TestCase {
public TC_Account(String arg0) {
super(arg0);
}
protected void setUp() throws Exception {
super.setUp();
}
public void testDeposit() {
Account account = new Account();
assertEquals("Account should start with no
funds.", 0, account.balance());
}
protected void tearDown() throws Exception {
super.tearDown();
}
}
|
つまり、
account.balance()
が0を戻すことを検査することになります。ただし、
Account
クラスがまだ存在しないため、このテストはコンパイルすらされません。図4は、このテストがコンパイルされない場合のワークスペースを示しています。
図4. コンパイルされないテスト・ケース
画面下部の「Tasks」ビューに、コンパイル・エラーが表示されます。いずれかのエラーをクリックすると、コード内の該当個所に移動しますので、非常に便利です。実際、Eclipseには、このような気の利いた機能がたくさん含まれています。例えば、コンパイルの問題があることを表示する方法は、何通りもあります。「Tasks」ビューにはエラーが表示されますし、エディターの左部分にはXの赤丸が表示されますし、ワークスペースの上部にあるすべてのビューにもXの赤が示されます。エディターの左部分にある (エラーがある行の隣の) Xの赤丸の上にマウス・ポインターを置くと、吹き出しテキストにエラー・メッセージが表示されます。
マウス・ポインターを好きな場所に移動させて、いろいろな部分をクリックし、「隠し」機能を探してみてください。いたるところに、そうした機能が隠れています。しかし、とりあえず当面の作業に戻りましょう。テストがコンパイルされていないのですから。テストがコンパイルされ、実行されて、失敗するために十分なコードのみを書いてください。できるだけ少しずつ作業を進め、できるかぎりコードを単純に保つことを忘れないでください。
com.sample
プロジェクトを選択してツールバーの「
New Java Class
」ボタンをクリックし、クラスの名前として「
Account
」と入力し、「
Finish
」をクリックして、
Account
クラスを作成してください。
Account
クラスでエディターがオープンするはずです。このクラスにはまだメソッドがありません。これに
balance()
メソッドを追加します。このクラスはリスト2のようになるはずです。
リスト2. Accountクラス
package com.sample;
public class Account {
public int balance() {
return 0;
}
}
|
テストを実行するために、「 TC_Account 」タイプを選択し、ツールバーにある走っている人の形をしたアイコンの隣のドロップダウン矢印をクリックし、「 Run As >JUnit Test 」と選択します。テストが実行され、画面の下部にビューとして表示されます。私は、JUnitを「Fast」ビューにするようにしています。それには、「JUnit」ビューをワークスペースの左側までドラッグし、「Fast」ビュー・バーにドロップします。そして、「 Window >Preferences >Java >JUnit 」を選択し、「 Show the JUnit results view only when a failure or error occurs 」チェック・ボックスにチェックマークを付けます。これにより、JUnit「Fast」 ビューはエラーまたは障害が発生するまで隠れるようになります。すべてがうまくいくと、アイコンの左下隅に緑のチェックが付けられます。こうしたほうが、すっきりします。
テストがコンパイルされるために十分なコードのみを書くと、この時点でのテストにはパスしますが、いつまでもこれで通用するわけではありません。ここでテスト・ケースにもう1つアサーションを追加して、誰かが
deposit()
メソッドを呼び出した後で新規残高をテストするようにします。この
testDeposit()
メソッドはリスト3のようになるはずです。
リスト3. deposit() メソッドのためのJUnitテスト
public void testDeposit() {
Account account = new Account();
assertEquals("Account should start with
no funds.", 0, account.balance());
account.deposit(5);
assertEquals("Account should reflect
deposit.", 5, account.balance());
}
|
ここでも、テストがコンパイルされるために十分なコードのみを書きます。この場合、具体的には、何もしない
deposit()
メソッドを
Account
に追加することを意味します。このクラスはリスト4のようになるはずです。
リスト4. 空のdeposit() メソッドを含むAccount
package com.sample;
public class Account {
protected int balance;
public int balance() {
return balance;
}
public void deposit(int amount) {
}
}
|
走っている人の形をしたアイコンを再びクリックして、テストを再実行してください。JUnit「Fast」ビューが展開され、「Account
should reflect
deposit」というメッセージで障害が表示されます。このようにテストが失敗することにより、どのようなコードを書くべきなのかが正確に示されます。テストにパスするために十分なコードのみを書きます。
deposit()
メソッドが預金額を
balance
に追加させるだけで十分なはずです。このテストを再実行すると、今度はパスするはずです。
「テストを書き、それにパスするのに十分なだけのコードを書いて、テストを再実行する」という方法は、私たちが毎日実践すべきXP開発の流れです。JUnitはEclipseに組み込まれているため、安心してコーディングに専念することができます。テストの実行は、いとも簡単に行えます。テストの作成も、Eclipseによってコードが生成され、ありきたりの入力を行う手間がかなり省けるので簡単に行えます。それでも考える必要はあるのですが、それも重要な事柄に限られます。
Account
クラスは、今度はリスト5のようになるはずです。
リスト5. deposit() メソッドが実装されたAccount
package com.sample;
public class Account {
protected int balance;
public int balance() {
return balance;
}
public void deposit(int amount) {
balance += amount;
}
}
|
これで、預金を入金できるようになりました。しかし、預金の引き出しもできないと困ります。
Account
で
withdraw()
メソッドに関して行うテストを書いてください。このテストはリスト6のようになるはずです。
リスト6. Accountのための更新されたテスト
package com.sample;
import junit.framework.TestCase;
public class TC_Account extends TestCase {
public TC_Account(String arg0) {
super(arg0);
}
protected void setUp() throws Exception {
super.setUp();
}
public void testDeposit() {
Account account = new Account();
assertEquals("Account should start with
no funds.", 0, account.balance());
account.deposit(5);
assertEquals("Account should reflect
deposit.", 5, account.balance());
}
public void testWithdraw() {
Account account = new Account();
account.balance = 5;
account.withdraw(3);
assertEquals("Account should reflect
withdrawal.", 2, account.balance());
}
protected void tearDown() throws Exception {
super.tearDown();
}
}
|
何も行わない
withdraw()
メソッドを
Account
に追加して、テストがコンパイルされるようにしてから、テストを再実行してください。テストは失敗するはずです。ここで、
withdraw
メソッドを実装してください。
Account
クラスはリスト7のようになるはずです。
リスト7. withdraw() メソッドが実装されたAccount
package com.sample;
public class Account {
protected int balance;
public int balance() {
return balance;
}
public void deposit(int amount) {
balance += amount;
}
public void withdraw(int amount) {
balance -= amount;
}
}
|
すべてのテストにパスするはずです。次は、いよいよ組み込みです。「連続的な組み込み」がXPにおける重要なプラクティスの1つであることは、覚えておられることでしょう。すべてのテストにパスしたときには、コードをシステムに組み込むことができます。これをなるべく早く、しかも頻繁に行う必要があります。Eclipseを使用すると、とても簡単に行うことができます。
Eclipseワークスペースを組み込むための準備として、以下のステップに従ってください。このプロセスのためにはCVSをセットアップしておく必要があります。
- 「 Window >Open Perspective >Other >CVS Repository Exploring 」と選択して、CVSパースペクティブを開きます。
- 右マウス・ボタン・クリックして「 New >Repository Location 」を選択します。ユーザーのセットアップに必要なすべてのパラメーターを入力して、「 Finish 」をクリックします。リポジトリーの位置が、CVS Repositoriesビューのリストで示されます。それを展開すると、HEADストリーム、Branches項目、およびVersions項目が表示されます。HEADストリームは、組み込み先のメイン・コード・ストリームです (ユーザー独自の分岐を行って、後でHEADストリームとマージすることもできます)。
- CVSパースペクティブ・ウィンドウを閉じます。
システムにコードを組み込むには、以下のステップに従ってください。
-
Sampleプロジェクトを右マウス・ボタン・クリックします。 - 「 Team >Share Project 」と選択します。まだ組み込まれていないプロジェクトを「共用」にします。これを行う必要があるのは、通常は一度だけです。
- プロンプトが出されたときに、希望するリポジトリー位置を選択し、「 Finish 」をクリックします。
今回のXPは、「テストを書き、それにパスするのに十分なだけのコードを書き、テストを再実行し、組み込む」という流れになります。
ここで
TC_Account
に注目してください。なにかコードが重複していることに気付きましたか?両方のテスト・メソッドは、ともに
Account
をインスタンス化しています。JUnitフレームワークはそれぞれのテスト・メソッドの前に
setUp()
メソッドを実行しますので、そこが、それぞれのテストで必要なセットアップを行う論理箇所となります。
Account
オブジェクトのインスタンス化は、テストをパスします。
このリファクタリングも十分に単純ですが、Eclipseではさらに簡単に行うことができます。
-
エディターで
TC_Accountの個所を表示します。 -
「
testDeposit()」で「account」ローカル変数を右マウス・ボタン・クリックし、「 Refactor >Convert Local Variable to Field 」を選択します。 -
フィールドの名前として「account」を入力し、アクセス修飾子「
protected」を選択し、「 OK 」をクリックします。テスト・クラスには「account」という保護フィールドが含まれるようになり、テスト・メソッドによってそれが初期化されます。 -
accountを初期化する行をこのテスト・メソッドからsetUp()に移動し、宣言と初期化を他のテスト・メソッドから削除します。テスト・クラスはリスト8のようになるはずです。
リスト8. リファクタリングされたTC_Account
package com.sample;
import junit.framework.TestCase;
public class TC_Account extends TestCase {
protected Account account;
public TC_Account(String arg0) {
super(arg0);
}
protected void setUp() throws Exception {
super.setUp();
account = new Account();
}
public void testDeposit() {
assertEquals("Account should start with
no funds.", 0, account.balance());
account.deposit(5);
assertEquals("Account should reflect
deposit.", 5, account.balance());
}
public void testWithdraw() {
account.balance = 5;
account.withdraw(3);
assertEquals("Account should reflect
withdrawal.", 2, account.balance());
}
protected void tearDown() throws Exception {
super.tearDown();
}
}
|
まだ、行わなければならない作業が残っていましたが、Eclipseのおかげで、少なくとも退屈な入力作業はある程度削減されます。しばらく続けると、こうした削減効果もばかにならなくなります。コンテキスト・メニューで使用可能なその他のリファクタリングを調べてください。次のように、非常に強力で、時間を大幅に短縮する効果を持つものもあります。
-
エディターで
Accountの個所を表示し、メソッド名balance()を右マウス・ボタン・クリックします。 - 「 Refactor >Rename 」と選択し、新しい名前として「getBalance」を入力します。
- 「Update references to the renamed element」にチェックマークが付いていることを確認し、「 OK 」をクリックします。
たったこれだけの作業で、
Account
のアクセサー・メソッドの名前が変更され、それに対するすべての参照が更新されました。テストを再実行し、まだすべてが機能することを確認してください。1つのクラスだけでも、1分またはそれ以上の時間を要する入力作業が楽々と省略できました。巨大なシステムで複数のクラスが
getBalance
を呼び出すとすると、どれほどの効果が得られるか想像してみてください。街角で踊り出したくなったとしても不思議ではありません。しかも、ありがたいことに、リファクタリングのやり直しがきくのです。新しい名前を打ち間違えて「getbalancew」と入力してしまった場合には、やり直せばよいのです。リファクタリングは簡単に行えますので、もう一度やり直して名前を変更してください。
ここで、再び組み込みを行います。流れは覚えていますよね?コードを若干変更し、テストを再実行しました。
-
「
Sample」プロジェクトを右マウス・ボタン・クリックし、「 Team >Synchronize with Repository 」と選択して、画面の下部で「Synchronize」ビューを開きます。青いタイトル・バーをダブルクリックして展開します。 - ツールバーの右側にある「 Incoming/Outgoing Mode 」ボタンをクリックします。このビューには、すべての着信変更および発信変更が表示されます。つまり、EclipseはCVSとインターフェースし、ワークスペースの内容とCVSの内容との間のデルタを表示します。
-
これまで何もコミットしていませんので、「Structure Compare」ビューで「
Sample」プロジェクトを右マウス・ボタン・クリックし、「 Commit 」を選択します。
デルタがある場合にどのようなことが起こるのかを調べるために、「
Account
」クラスに戻り、「
deposit()
」メソッドへの「
amount
」パラメーターを右マウス・ボタン・クリックし、「
Refactor>Rename
」と選択してください。名前を「anAmount」に変更します。ほら、変わったでしょう?テストを再実行してください。すべてがテストにパスするはずです。プロジェクトを右マウス・ボタン・クリックし、再び同期化してください。図5のような画面が表示されます。「
Account
」クラスをダブルクリックすると、先ほど作成されたデルタが表示されます。これを保管したいので、プロジェクトを右マウス・ボタン・クリックして「
Commit
」を選択します。
図5. 同期化されたビュー
プロジェクトが開始された後ですぐに、すべてのXPチームが毎日の終わりにシステム全体をビルドするようにしてください。こうすることにより、稼働するシステムを見る必要のある人 (例えば、顧客) に、それを提供することができます。これはまた、チームのためにチェックポイントを提供することにもなります。ひどい間違いを犯してしまった場合には、前日稼働していたシステムにいつでも戻ることができます。チームの信頼感を高めるうえで、安全策にまさるものはありません。
JakartaによるAntプロジェクトは、すばらしいビルド・ツールです。ビルド・スクリプトはXMLで書きます。XMLの「target」はややなぞめいている気がしますが、行われていることが理解できるようになると、そうした違和感は薄らいでいきます。しかし、正直なところ、しばらくAntを使用しないでいると、基本的なことをする場合でさえ、たくさんの情報を調べ直すことが必要になります。いずれにしても、Eclipseには、非常に役に立つAntプラグインが付属しています。この統合は、ほとんどシームレスに行われています。
私たちのプロジェクトのために、どこかにあるハード・ディスク (実際には、ネットワーク・ドライブまたはその他のなんらかのドライブ) のデプロイメント・ディレクトリーにファイルをコピーする、サンプル・ビルドを作成することにしましょう。
-
ワークスペースで「
Sample」プロジェクトを選択します。 - 「 File >New >Other 」と選択します。
- 「 Simple 」を選択してから「 File 」を選択します。
- 新規ファイルにbuild.xmlという名前を付けます。Eclipseがそのファイルを作成し、エディターでそのファイルを開きます (タイトル・バーにあるアイコンが、かわいらしいアリのアイコンになっていることに注意してください)。ビルド・スクリプトは、リスト9のようになります。
リスト9. ビルド・スクリプト
<project name="Sample" default="build" basedir=".">
<property name="project" value="${basedir}"/>
<property name="tempDirectory" value="${project}/temp"/>
<property name="runtimeClasses"
location="${project}/lib/runtime.jar"/>
<property name="deployDirectory" location="c:/deploy"/>
<patternset id="non.test.classes" >
<include name="**/*.class"/>
<exclude name="**/TC_*.class"/>
</patternset>
<target name="build">
<antcall target="clean"/>
<antcall target="init"/>
<antcall target="build.Sample"/>
<antcall target="clean"/>
</target>
<target name="init">
<mkdir dir="${tempDirectory}"/>
<mkdir dir="${deployDirectory}"/>
</target>
<target name="build.Sample">
<javac srcdir="${project}/src"
destdir="${tempDirectory}"
>
<exclude name="**/TC_*.java"/>
</javac>
<jar destfile="${deployDirectory}/sample.jar">
<fileset dir="${tempDirectory}"></fileset>
</jar>
</target>
<target name="clean">
<delete dir="${tempDirectory}"/>
</target>
</project>
|
Antはtarget
に基づいています。targetはAntの実行に必要な作業単位を記述します。この場合、targetは3つあります。最初は、build
というメインtargetです。
project
タグの
default
属性で、buildがデフォルトtargetとして識別されています。このtargetは、他の3つのtarget
、つまり
clean
、
init
、および
build.Sample
を呼び出します。これがJavaコードの場合には、デフォルトtargetを代理メソッドとして記述することができます。このtargetは、他のtargetを適切な順序で呼び出します
(これはある意味で、Template Methodパターンの実装です)。このメインtargetは最初に
clean
を呼び出して操作が新規に開始されるように確保してから、
init
を呼び出して必要なディレクトリーをセットアップします。メインtargetは次に
build.Sample
を呼び出し、さらに
clean
を再度呼び出します。
build.Sample
は、アクションが行われるtargetです。
build.Sample
では、以下のことが行えます。
- ローカル・ハード・ディスクにデプロイメント・ディレクトリーを作成します。
-
テスト・ケースを除く (これらを配置する必要はありません) すべての
Sampleプロジェクト・ソースを、一時ディレクトリーにコンパイルします。 - コンパイル済みのクラスを一時ディレクトリーでJAR圧縮して、デプロイメント・ディレクトリーに収めます。
Antスクリプトを実行するには、「Resource」パースペクティブに移動し、「
build.xml
」を右マウス・ボタン・クリックして「
Run Ant
」を選択してください。これにより、デフォルトのtargetが選択された状態でダイアログが起動します。「
Run
」をクリックします。障害がある場合、Eclipseは画面下部にAntコンソールを表示します。これは、Antに関する私の最大の不満です。うまくいかないことがあった場合、デバッグが大変なのです。幸いなことに、Echo
Ant targetを使用することにより、
System.out.println()
と等価な機能が得られます。スクリプトに不備があった場合、そこに
<echo>some helpful message</echo>
を追記して、どのようになっているのかを調べやすくすることができます。このケースの場合のエラーは、扱いに慎重を要するものです。Antは、
tools.jar
を検出することができないと訴えています。読者はAntに対し、コンパイルに必要なJavaクラスがどこで見つけられるのかを知らせる必要があります。そのためには、以下のステップに従ってください。
-
「
Sample」プロジェクトを選択します。 - 「 File >Import 」と選択し、「 File System 」を選択します。
-
インストール済みのJDKの
libディレクトリーまでブラウズします。 -
「
tools.jar」ファイルを選択し、「 Finish 」をクリックします。
この一連のステップが完了すると、
Sample
プロジェクトに
lib
ディレクトリーが作成され、そのディレクトリーに
tools.jar
が入ります。次に、以下のようにしてその場所をAntに指示してください。
- 「 Preferences >Ant >Runtime 」と選択します。下部に「Additional classpath entries:」と表示されるはずです。
- 「 Add JARs... 」ボタンをクリックし、「 Sample/lib/tools.jar 」を選択します。これで、コンパイラーの見つけ方がAntに分かるようになります。
-
「
build.xml」を右マウス・ボタン・クリックし、Antを再実行します。エラーが起こらず、c: ¥ deployにsample.jarが作成されるはずです。
皆さんは、「必携」リストに載るツールがあまり多くないことに気が付くはずです。手に入れたいと思うようなEclipseプラグインはほかにもあることでしょうし、特定のプロジェクトをサポートするために、おそらく、さらにいくつかのJava言語ライブラリーが必要になることと思われますが、多くのプロジェクト・チームが必要と考えるほどには、たくさんのツールを用意する必要はありません。XPを使用している場合、必要な管理ツールは、いくつかのノート・カードと、おそらく1つのスプレッドシートのみです。それ以外のものはすべて開発者ツールであり、そうしたツールのリストは、小さなままにしておく必要があります。状況が改善されるというのでないかぎり、ツールの追加には抵抗するべきだと思います。状況を改善してくれるのであれば、ぜひお使いください。優れたツールを使用すると、つまらないプロジェクトと愉快なプロジェクトを見分けることができます。私のリストの筆頭にあるのは、Eclipse、JUnit (さらにshamsやHttpUnitなどのテスト支援プログラム)、およびAntです。また、アプリケーション・サーバーが必要な場合には、誰かにとがめられるまではTomcatを使用してください。
-
このコラムを、シリーズの途中から読み始めましたか?Chris
Collins氏との共著による最初の記事、「
XPの真髄
」(developerWorks、2001年3月) を参照してください。その後で、このシリーズの
すべての記事
を参照してください。
-
Eclipseの最も強力な機能の1つは、Daniel Steinberg氏が述べているように、一連の「
automated refactoring (自動化されたリファクタリング)
」です (developerWorks、2001年11月)。
-
eclipse.org
からEclipseをダウンロードしてください。また、このサイトには多数の優れた技術関連記事も掲載されています。
-
developerWorks Open source projects
では、Eclipseに関する豊富な情報が提供されています。
-
JUnit
は、Java言語でプログラマー・テストを書くための優れたツールです。このサイトは数多くの書籍やツールにリンクされています。
-
VisualAge for JavaがXPチームのための最善のツールであることは、「
Extreme Programming with IBM VisualAge for Java
」(developerWorks、2001年4月) で説明されています。
-
developerWorks Java technology zone
には、Javaプログラミングのあらゆる側面についての豊富な記事が用意されています。
Roy W. Millerは最初にAndersen Consulting (現在のAccenture)にて、10年以上技術コンサルタント、ソフトウェア開発者、および指南役を務め、ノースキャロライナのRoleModel Software社にてほぼ3年を過ごしました(ここでは彼は、エクストリームプログラミング(XP)を使用したJava言語アプリケーションの構築に注力しました)。現在、彼は独立コンサルタントであり指南役です。彼は、XPを含む重要なメソッドおよび機動的なメソッドを使用しており、Addison-Wesley XP Series (Extreme Programming Applied: Playing to Win)中で本を共同執筆しました。彼の最も最近の本であるManaging Software for Growth: Without Fear, Control, and the Manufacturing Mindsetは、どのように、複雑な技術がソフトウェア開発を支援することができ、そして他のITマネージャー達が、プログラマをコントロールしたり枯らすことなく、彼らのチームが実際の人々が使用して楽しいような素晴らしいソフトウェアを作成することの、支援方法を理解するかを述べています。Royの連絡先は、roy@roywmiller.comです。