Apache Ant site Apache Ant logo

the Apache Ant site
Home
Projects
 

問題があります?

問題があります?

このページでは、Ant で起こりうる問題を解決へと導く手順について詳しく説明します。 問題を解決できないとわかった場合、バグレポートに記入するための関連情報を収集する方法を導きます。 この情報は、Ant の開発者が問題を理解し解決するのに役立ちます。 もちろん、ここには全ての手順があるわけではないので、発生した全ての問題に対応しているわけではありません ―― 単に、これらは、皆さんに正しい方向を示すための提案にすぎません。

Read the Manual

Ant で問題が起きたときは、まず、 マニュアル中の、問題となっているタスクや概念の項目を読んでください。 特に、タスクの属性や内部要素の意味を確認してください。 おそらく、やりたいことを提供する属性があるでしょう。 マニュアル自身に問題がある場合には、 Ant のドキュメントをより良いものにするため、 ドキュメントのバグレポート(後述)を投稿してください。

デバッグ出力を調べてください

まだ問題がある場合の次の手順は、Ant が行っていることについての追加情報を集めることです。 Ant にverboseフラグをつけて実行してみてください:

ant -verbose

または ant -v

とすると、次のように始まる出力が生成されます:

Ant version 1.4.1 compiled on October 11 2001
Buildfile: build.xml
Detected Java version: 1.3 in: D:\usr\local\java\jdk13\jre
Detected OS: Windows NT
parsing buildfile D:\ant\build.xml with URI = file:D:/ant/build.xml
Project base dir set to: D:\ant
??[property] Loading Environment env.
??[property] Loading D:\ant\conf.properties
Build sequence for target 'debug' is [debug]
Complete build sequence is [debug, gensrc, compile, jar, test]
. . .

このトレース結果から、Ant の実行内容についてや、 ある特定のアクションが実行される理由となる経路を把握できるでしょう。 より多くの情報が必要であれば、 -verboseよりむしろ、-debugフラグを使用することができます。 一般に、これはかなり多くの出力を発生させるので、 出力をファイルに保存して、エディタ上で解析すべきです。 リダイレクションや -logfile <filename>フラグを使えば、 出力を保存することができます。

デバッグ情報を全て得たはいいが、このあとどうすれば問題を解決できるのでしょうか? これは、タスクや問題の性質に依存します。 個々のタスクは、その操作のそれぞれ異なる側面をログに記録しますが、 何が起こっているのかというヒントにはなるでしょう。 例えば <javac>タスクは、なぜそのクラスをコンパイル対象にし、他を対象外としたかという理由、 使用するコンパイラと渡される引数をログに出力します。 次に示すトレースでは、<javac> が、 もう一つのクラスをスキップするにもかかわらず、 一つのクラスファイルを追加するのか、 という理由を示しています。 これに続き、使用されるコンパイラ、渡される引数、 コンパイルされる全てのクラスの一覧が表示されます。

[javac] Test.java omitted as D:\classes\Test.class is up to date.
[javac] Unset.java added as D:\classes\Unset.class is outdated.
[javac] Compiling 1 source file to D:\classes
[javac] Using classic compiler
[javac] Compilation args: -d D:\classes -classpath D:\classes;
D:\jdk118\classes.zip; -sourcepath D:\src\java -g:none
[javac] File to be compiled:
D:\src\java\Unset.java

多くの場合、Ant のタスクは OS コマンドや Java クラスのラッパーです。 デバッグモードでは、これらのタスクの多くが <javac>と同様のコマンドラインを出力します。 問題がある場合、 Ant と同じ方法で、コマンドラインから直接コマンドを実行してみて、 その場所で問題が起きているか見るという方法も有用です。 問題は実行されるコマンドにあるか、Ant タスクがコマンドを実行する方法にあります。 属性値を変えてみて、生成されるコマンドラインにどう影響するかを観察することもできます。 これにより、正しい属性と値を使っているかどうか判断できます。

その問題は修正済みですか?

デバッグ出力を確認してもなお、 起きている問題が Ant によるものだと考えられる場合、 他の人が既にこの問題に遭遇していて、 恐らく修正されている可能性が大きいです。 したがって次の手順は、 問題が修正済かどうか、Ant のナイトビルドを試すことです。 Ant ウェブサイト で入手できます。 Ant ナイトビルドは Gump によって、 他の多くの Jakarta プロジェクトをビルドするために使われていて、 だいたいは安定しているのですが、試験的ビルドである可能性もあります。 ナイトビルドでは Ant に付属するオプションタスクの多くをビルドしていません。 これらのオプションタスクのスナップショットは、 ナイトダウンロードエリアに、 ときどきアップロードされます。 しかし、このスナップショットには全てのオプションタスクが入っているわけではありません。

その問題は報告済ですか?

現在のナイトビルドでも問題が解決しない場合でも、 その問題は他の誰かが報告済である可能性があります。 いよいよ、Apacheバグデータベース を見る時がきました。 このシステムを使うのは簡単です。 その問題が既に報告されていれば、 現在作業中 および、解決されたバグを探すことができます。 問題が報告されていた場合、開発者の誰かによる、バグの理由や回避方法などのコメントを見ることが出来ます。 あるいは、あなたが追加情報を持っているなら(後述のバグレポートの作成と変更についてご覧ください)、 先に進み、情報を追加してください。 何も追加情報が無いときは、単にこのバグに投票し、 このバグの進捗を見守るために自分(のメールアドレス)をCCリストに加えても構いません。

バグレポートへの記入

この時点で、Antに報告されていないバグがあると判断できます。 幾つかの選択肢があります。 まず、userメーリングリストにメールを送って、 他の誰かが同じ問題に直面していないか、その人はどのように対処したか聞いてみることができます。 幾つかの議論ののち、バグレポートを作成する時期が来ていると思ったら、 バグデータベースの簡単な操作を行うときです。 開発者がバグを解決するのを助けるために、できるだけ多くの情報を提供するように心がけてください。 また、どのバージョンのAntで実行したか、どのような動作環境で実行したかなど、 バグが発生した時の様々な入力に対する正しい値を入力するように心がけてください。 バグを生成できたら、バグレポートに添付することもできます。

バグレポートにはどのような情報を入れるべきでしょうか? 簡単に修復できるバグとは、簡単に再現できるバグです。 ですから、問題を再現できる小さなテストケースを作成できたら本当に助かります。 この場合、ビルドファイルと、問題を再現するのに必要な他のファイルを、恐らくアーカイブにまとめて添付します。 テストケースを作成できない場合には、 自分のビルドファイルの一部と、 Ant のverbose出力あるいはデバッグ出力の関連する部分を添付してみてください。 Antがバージョン、OS、VMの情報などを明記したヘッダ情報をいれてみてください。 デバッグ情報はとても大きくなりがちなので、 関係ない出力は削除してしまうと良いでしょう。 バグ情報がバグデータベースに入力されたら、 そのバグに対する進捗についてメールでずっと連絡が来ます。 詳しい情報を求めるメールを受け取った場合には、 自分のバグを解決する助けとなるよう、返事を送ってください。

機能拡張のリクエスト

場合によっては、Ant が自分が必要としている動作をしないこともあります。 Antは期待されたとおりに動作しているので、バグとはいえません。 それはまだ考えられていないような、タスクの追加機能か、 全く新しいタスクであるかもしれません。 このような場合には、機能拡張のリクエストを提案したくなるでしょう。 機能拡張のリクエストは、上述の同じ Apache バグデータベースを使って管理されています。 これらは単に異なる種類のバグレポートなのです。 バグデータベースを見ると、バグの重要度の設定の一つに "Enhancement(機能拡張)" があるのがわかるでしょう。 単に、バグレポートを記入し、バグ重要度を "Enhancement" に設定し、 Ant をどう拡張したいかについて記述します。 繰り返しになりますが、まず最初に、自分の要求を満足する拡張機能のリクエストがないか確認してください。 もしあれば、単にそれに投票してください。

Fixing the Bug

If you aren't satisfied with just filing a bug report, you can try to find the cause of the problem and provide a fix yourself. The best way to do that is by working with the latest code from CVS. Alternatively, you can work with the source code available from the source distributions. If you are going to tackle the problem at this level, you may want to discuss some details first on the dev mailing list. Once you have a fix for the problem, you may submit the fix as a patch to either the dev mailing list, or enter the bug database as described above and attach the patch to the bug report. Using the bug database has the advantage of being able to track the progress of your patch.

バグレポートに記入するだけでは満足しない場合、 問題の原因の究明を試み、自分でバグを修正することもできます。 CVS にある最新のコードで作業するのが最適です。 あるいは、 ソースコード配布 にあるソースコードでも作業できます。 このレベルで問題に取り掛かろうしている場合には、 先に、ant-devメーリングリストで詳細について議論してもよいでしょう。 問題を修正したら、その修正をパッチとして devメーリングリストに投稿するか、 上述のようにバグデータベースに入力し、バグレポートにパッチを添付してください。 バグデータベースを使った場合、 自分のパッチの進捗を追うことができるという利点があります。

投稿するパッチがあり、devメーリングリストに送る場合には、 記事の件名の前に "[PATCH]" とつけてください。 関連するバグ番号も入れてください。 パッチファイルは diffcvs diff-u オプションで作ってください。 例えば:

diff -u Javac.java.orig Javac.java > javac.diffs

または、CVSからのソースがある場合:

cvs diff -u Javac.java > javac.diffs

注意: パッチファイルには意味のある名前をつけてください。 こうすることで、 複数の異なるパッチをあてる必要のある開発者の作業が楽になります。