Apache Ant

Apache Ant

ダウンロード

プロジェクト参加

トラブル

This page details some steps you can take to try and resolve any problems you may be having with Ant. If you find you can't resolve the problem, then this page will help you collect some of the relevant information to provide in a bug report. This information will help the Ant developers understand and resolve the problem. Of course, not all the steps here will make sense for every problem you may encounter - these are just some suggestions to point you in the right direction.

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

マニュアルを読んでください/Read the Manual

The first step to take when you have a problem with Ant is to read the manual entry for the task or concept that is giving you trouble. In particular, check the meaning of a task's attributes and nested elements. Perhaps an attribute is available that would provide the behavior you require. If you have problems with the manual itself, you can submit a documentation bug report (see below) to help us improve the Ant documentation.

Ant で問題が起きたときに採る最初の手順は、 問題となっているタスクや概念のマニュアル中の項目を読むことです。 特に、タスクの属性やネストされた要素の意味を確認してください。 恐らく、 必要とする振る舞いを提供する属性が利用可能なはずです。 マニュアル自身に問題がある場合には、 Ant のドキュメントをより良いものにするために、 ドキュメントバグレポート(後述)に投稿してください。

デバッグ出力を確認してください/Examine Debug Output

If you're still having a problem, the next step is to try and gather additional information about what Ant is doing. Try running Ant with the verbose flag:

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



ant -verbose

または / or

ant -v

This will produce output that starts like the following:

これにより、次のように始まる出力を生成します:

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]
. . .

You should be able to see from the trace more about what Ant is doing and why it's taking a particular course of action. If you need even more information, you can use the -debug flag rather than -verbose. This will generally produce so much output that you may want to save the output to a file and analyze it in an editor. You can save the output using the -logfile <filename> flag, or using redirection.

トレース結果より Ant の実行内容についてや、 特定の動作の経過とる理由について、より理解できるでしょう。 より多くの情報が必要な場合には、 -verboseよりも、 -debugフラグが利用可能です。 一般に、これはかなり多くの出力を表示するので、 出力をファイルに保存して、エディタ上で解析したほうがいいでしょう。 -logfile <filename>フラグや、 リダイレクションを使えば、 出力を保存できます。

Once you have all this debug information, how can you use it to solve your problem? That will depend on the task in question and the nature of your problem. Each task logs different aspects of its operation, but it should give you an idea of what is going on. For example, the <javac> task logs the reasons why it chooses to compile particular class files and not others, along with which compiler it is using and the arguments it will pass to that compiler. The following partial trace shows why <javac> is adding one class file but skipping another. This is followed by which compiler it will be using, the arguments that will get passed to the compiler, and a list of all the class files to be compiled.

このデバッグ情報を全て得たら、 問題を解決するのに、どうつかえばいいのでしょうか。 これは問題となっているタスクや、問題の性質に依存しています。 個々のタスクは、その操作のそれぞれ異なる側面をログ記録しますが、 何が起こっているのかというヒントを与えるでしょう。 例えば、<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

In many cases, Ant tasks are wrappers around OS commands or other Java classes. In debug mode, many of these tasks will print out the equivalent command line, as the <javac> task output does. If you are having a problem, it is often useful to run the command directly from the command line, in the same way Ant is running it, and see if the problem occurs from there as well. The problem may be in the command that is being run, or it may be in the way the Ant task is running the command. You can also see the effect of changing attribute values on the generated command line. This can help you to understand whether you are using the correct attributes and values.

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

その問題は修正済みですか/Has It Been Fixed?

After examining the debug output, if you still believe that the problem you are having is caused by Ant, chances are that someone else may have already encountered this problem, and perhaps it has been fixed. The next step, therefore, may be to try a nightly build of Ant to see if the problem has been fixed. Nightly builds for Ant are available from the Jakarta web site. While Ant nightly builds are typically quite stable and are used by Gump to build many other Jakarta projects, these builds should nonetheless be treated as experimental. Note that nightly builds do not build many of the optional tasks the come with Ant. A snapshot of these optional tasks is occasionally uploaded to the nightly download area. However, even this snapshot does not contain every optional task.

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

その問題は報告済ですか/Has It Been Reported?

If the current nightly build doesn't resolve your problem, it is possible that someone else has reported the issue. It is time to look at the Apache Bug Database. This system is easy to use, and it will let you search the currently open and resolved bugs to see if your problem has already been reported. If your problem has been reported, you can see whether any of the developers have commented, suggesting workarounds, or the reason for the bug, etc. Or you may have information to add (see about creating and modifying bug reports below), in which case, go right ahead and add the information. If you don't have any additional information, you may just want to vote for this bug, and perhaps add yourself to the CC list to follow the progress of this bug.

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

バグレポートへの記入/Filing a Bug Report

By this time, you may have decided that there is an unreported bug in Ant. You have a few choices at this point. You can send an email to the ant-user mailing list to see if others have encountered your issue and find out how they may have worked around it. If after some discussion, you feel it is time to create a bug report, this is a simple operation in the bug database. Please try to provide as much information as possible in order to assist the developers in resolving the bug. Please try to enter correct values for the various inputs when creating the bug, such as which version of Ant you are running, and on which platform, etc. Once the bug is created, you can also add attachments to the bug report.

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

What information should you include in your bug report? The easiest bugs to fix are those that are most easily reproducible, so it is really helpful if you can produce a small test case that exhibits the problem. In this case, you would attach the build file and any other files necessary to reproduce the problem, probably packed together in an archive. If you can't produce a test case, you should try to include a snippet from your build file and the relevant sections from the verbose or debug output from Ant. Try to include the header information where Ant states the version, the OS and VM information, etc. As debug output is likely to be very large, it's best to remove any output that is not relevant. Once the bug is entered into the bug database, you will be kept informed by email about progress on the bug. If you receive email asking for further information, please try to respond, as it will aid in the resolution of your bug.

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

機能拡張のリクエスト/Asking for an Enhancement

Sometimes, you may find that Ant just doesn't do what you need it to. It isn't a bug, as such, since Ant is working the way it is supposed to work. Perhaps it is some additional functionality for a task that hasn't been thought of yet, or maybe a completely new task. For these situations, you will want to raise an enhancement request. Enhancement requests are managed using the same Apache Bug Database described above. These are just a different type of bug report. If you look in the bug database, you will see that one of the severity settings for a bug is "Enhancement". Just fill the bug report in, set the severity of the bug to "Enhancement", and state in the description how you would like to have Ant enhanced. Again, you should first check whether there are any existing enhancment requests that cover your needs. If so, just add your vote to these.

場合によっては、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 ant-dev mailing list. Once you have a fix for the problem, you may submit the fix as a patch to either the ant-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メーリングリストで詳細について議論してもよいでしょう。 問題を修正したら、 その修正をパッチとして、 ant-devメーリングリストに投稿するか、 上述のようにバグデータベースに入力し、バグレポートにパッチを添付してください。 バグデータベースを使った場合、 自分のパッチの進捗を追うことができるという利点があります。

If you have a patch to submit and are sending it to the ant-dev mailing list, prefix "[PATCH]" to your message subject. Please include any relevant bug numbers. Patch files should be created with the -u option of the diff or cvs diff command. For example:

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

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

or, if you have source from CVS:

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

cvs diff -u Javac.java > javac.diffs

Note: You should give your patch files meaningful names. This makes it easier for developers who need to apply a number of different patch files.

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


Copyright © 2000-2002, Apache Software Foundation
[訳注:これは漆島賢二が翻訳しました。日本語訳に対するコメントがあれば こちらに送ってください]