Apache Ant site Apache Ant logo

the Apache Ant site
Home
Projects
 

Frequently Asked Questions

Questions

About this FAQ

General

Installation

How do I ...

It doesn't work (as expected)

Ant and IDEs/Editors

Advanced Issues

Known Problems

Answers

Where do I find the latest version of this document? − このドキュメントの最新版はどこにありますか?

The latest version can always be found at Ant's homepage http://ant.apache.org/faq.html.

最新版はいつでも Ant のホームページ http://ant.apache.org/faq.html で見つかります。

[訳注:日本語版は jajakarta のホームページ http://www.jajakarta.org/ant/faq.html で見つかります。]

How can I contribute to this FAQ? − どうすれば、このFAQに協力できますか?

The page you are looking it is generated from this document. If you want to add a new question, please submit a patch against this document to one of Ant's mailing lists; hopefully, the structure is self-explanatory.

If you don't know how to create a patch, see the patches section of this page.

ご覧のページはこのドキュメントから生成されています。 新しい質問を加えたい場合には、 このドキュメントに対するパッチを Ant メーリングリストのどれかに送ってください; できれば、構造が自明なもので。

パッチの作り方を知らない場合には、このページのパッチの節をご覧ください。

How do you create the HTML version of this FAQ? − このFAQのHTML版をどうやって生成しますか?

We use Anakia to render the HTML version from the original XML file.

The Velocity stylesheets used to process the XML files can be found in the xdocs/stylesheets subdirectory of Ant's CVS repository - the build file docs.xml at the top level of the ant CVS module is used to drive Anakia.

This file assumes that you have the jakarta-site2 CVS module checked out as well, but if you follow the instruction from Anakia's homepage, you should get it to work without that. Just make sure all required jars are in the task's classpath.

オリジナルXMLファイルからHTML版を生成するのに Anakia を使っています。

XML ファイルを処理するのに使われる Velocity スタイルシートは Ant CVS リポジトリのxdocs/stylesheets サブディレクトリにあります - antモジュールのトップにある ビルドファイル docs.xml は Anakia を動かすのに使われています。

このファイルでは、 jakarta-site2 CVS モジュールも正しくチェックアウトされていると仮定していますが、 Anakia のホームページの説明に従っている場合には、 そのモジュールが無くても動きます。 全ての必要な jar ファイルがそのタスクのクラスパスにあるかだけ確認してください。

What is Apache Ant? − Apache Ant って何ですか?

Ant is a Java-based build tool. In theory, it is kind of like Make, without Make's wrinkles and with the full portability of pure Java code.

AntはJavaベースのビルドツールです。 理論的には、makeの持っているような問題点を持たない、 Pure Java コードの完全なポータビリティーを持つ makeの一種です。

Why do you call it Ant? − なぜ、これを Ant と呼ぶのですか?

According to Ant's original author, James Duncan Davidson, the name is an acronym for "Another Neat Tool".

Later explanations go along the lines of "ants do an extremely good job at building things", or "ants are very small and can carry a weight dozens of times their own" - describing what Ant is intended to be.

その名前は、 Ant のオリジナルの開発者である James Duncan Davidson によってつけられた、 "Another Neat Tool(別の素敵なツール)"の頭字語です。

後の説明では、 "Ant は何かを作るときにとてもよく働く"とか、 "Ant はとても小さくて、自分の体重の何倍もの重さのものを運べる" のような説明になり、Ant が何を意図しているのかを説明しています。

Tell us a little bit about Ant's history.? − Ant の歴史について少し教えてください

Initially, Ant was part of the Tomcat code base, when it was donated to the Apache Software Foundation. It was created by James Duncan Davidson, who is also the original author of Tomcat. Ant was there to build Tomcat, nothing else.

Soon thereafter, several open source Java projects realized that Ant could solve the problems they had with Makefiles. Starting with the projects hosted at Jakarta and the old Java Apache project, Ant spread like a virus and is now the build tool of choice for a lot of projects.

In January 2000, Ant was moved to a separate CVS module and was promoted to a project of its own, independent of Tomcat, and became Apache Ant.

The first version of Ant that was exposed to a larger audience was the one that shipped with Tomcat's 3.1 release on 19 April 2000. This version has later been referred to as Ant 0.3.1.

The first official release of Ant as a stand-alone product was Ant 1.1, released on 19 July 2000. The complete release history:

Ant Version Release Date
1.1 19 July 2000
1.2 24 October 2000
1.3 3 March 2001
1.4 3 September 2001
1.4.1 11 October 2001
1.5 10 July 2002
1.5.1 3 October 2002
1.5.2 3 March 2003
1.5.3 9 April 2003
1.5.4 12 August 2003
1.6.0 18 December 2003
1.6.1 12 February 2004

当初、Ant が Apache Software Foundation に寄贈された時は、 Tomcat のコードの一部でした。 Ant は、Tomcat のオリジナルの開発者でもある James Duncan Davidson によって作られました。 Ant は他のためではなく、Tomcat をビルドするために存在したのです。

それからすぐ後、幾つかのオープンソース Java プロジェクトにより、 Ant が Makefile にあった問題を解決できると気づいたのです。 Jakarta で行われたプロジェクトや古い Java Apache プロジェクトに始まり、 Ant はウィルスのように広がり、 今や、多くのプロジェクトのビルドツールに選ばれました。

2000年1月に Ant は別の CVS モジュールとなり、 Tomcat から独立して、 Ant 単体のプロジェクトに昇進し、 Apache Ant となりました。

大勢のプログラマに利用された Ant の最初のバージョンは 2000年 4 月 19 日の Tomcat 3.1 リリースで配布されたものでした。 このバージョンは後に Ant 0.3.1 として参照されています。

単体の製品としての Ant の最初の公式リリースは、 2000 年 7 月 19 日にリリースされた Ant 1.1 です。 全リリース履歴は次の通りです:

Ant バージョン リリース日
1.1 2000年7月19日
1.2 2000年10月24日
1.3 2001年3月3日
1.4 2001年9月3日
1.4.1 2001年10月11日
1.5 2002年7月10日
1.5.1 2002年10月3日
1.5.2 2003年3月3日
1.5.3 2003年4月9日
1.5.4 2003年8月12日
1.6.0 2003年12月18日
1.6.1 2004年2月12日

I get checksum errors when I try to extract the tar.gz distribution file. Why? − tar.gz配布ファイルから取り出そうとしたら、 チェックサムエラーが出ました。どうしてですか?

Ant's distribution contains file names that are longer than 100 characters, which is not supported by the standard tar file format. Several different implementations of tar use different and incompatible ways to work around this restriction.

Ant's <tar> task can create tar archives that use the GNU tar extension, and this has been used when putting together the distribution. If you are using a different version of tar (for example, the one shipping with Solaris), you cannot use it to extract the archive.

The solution is to either install GNU tar, which can be found here, or use the zip archive instead (you can extract it using jar xf).

Ant の配布物には、標準の tar ファイルフォーマットでは サポートされていない 100 文字以上の長さのファイル名が含まれています。 tar の幾つかの異なる実装では、 この制限の扱うために異なる互換性の無い方法を用いています。

Ant の <tar> タスクは GNU tar の拡張を用いて tar アーカイブを作ることができ、 これは配布物を一まとめにするのに使われています。 違うバージョンの tar (例えば、Solaris で配布される物)を 使っている場合、それはアーカイブを展開するのには使えません。

解決策はここにある GNU tar をインストールするか、代わりに zip アーカイブ (jar xfを使って取り出せます)を使うかです。

How do I add an external task that I've written to the page "External Tools and Task"? − 作成した外部タスクを "外部ツールとタスク" ページに追加するにはどうすればいいですか?

Join and post a message to the dev or user mailing list (one list is enough), including the following information:

  • the name of the task/tool
  • a short description of the task/tool
  • a Compatibility: entry stating with which version(s) of Ant the tool/task is compatible to
  • a URL: entry linking to the main page of the tool/task
  • a Contact: entry containing the email address or the URL of a webpage for the person or list to contact for issues related to the tool/task. Note that we'll add a link on the page, so any email address added there is not obfuscated and can (and probably will) be abused by robots harvesting websites for addresses to spam.
  • a License: entry containing the type of license for the tool/task

The preferred format for this information is a patch to this document.

dev または user メーリングリスト(どちらか片方で十分です) に加入し、以下の情報を書いた記事を投稿してください:

上記情報の推奨フォーマットは、 この 文書に対するパッチ形式です。

How do I pass parameters from the command line to my build file? − 自分のビルドファイルにコマンドラインからパラメータを渡すにはどうすればいいですか?

Use properties. Using ant -Dname=value lets you define values for properties on the Ant command line. These properties can then be used within your build file as any normal property: ${name} will put in value.

プロパティを使います。 ant -Dname=value を使えば、 Ant のコマンドラインでプロパティの値を定義できます。 これらのプロパティは自分のビルドファイル中で通常のプロパティのように使われます: ${name} には、 value が代入されます。

How can I use Jikes-specific command-line switches? − どうすれば Jikes 特有のコマンドラインスイッチを使えますか?

A couple of switches are supported via "magic" properties:

switch property default
+E build.compiler.emacs false == not set
+P build.compiler.pedantic false == not set
+F build.compiler.fulldepend false == not set
(Only for Ant < 1.4; replaced by the nowarn attribute of the <javac> task after that.)
-nowarn
build.compiler.warnings true == not set

With Ant >= 1.5, you can also use nested <compilerarg> elements with the <javac> task.

"魔法の"プロパティにより幾つかのスイッチがサポートされています:

スイッチ プロパティ デフォルト
+E build.compiler.emacs 設定されない場合false
+P build.compiler.pedantic 設定されない場合false
+F build.compiler.fulldepend 設定されない場合false
(Ant 1.4 より前のみ; それ以降では、 <javac>タスクの nowarn属性に置き換えられました。)
-nowarn
build.compiler.warnings 設定されない場合true

Ant 1.5 以降では、内部要素 <compilerarg><javac>タスクを使うこともできます。

How do I include a < character in my command-line arguments? − コマンドライン引数で < 文字を入れるにはどうすればいいですか?

The short answer is "Use: &lt;".

The long answer is that this probably won't do what you want anyway (see the next section).

一言で答えるなら "&lt; を使え" です。

ただし、たぶんこれではあなたのやりたい事はできないでしょう (次の節も見てください)。

How do I redirect standard input or standard output in the <exec> task? − タスクの標準入力や標準出力をリダイレクトするにはどうすればいいですか?

Say you want to redirect the standard output stream of the m4 command to write to a file, something like:

shell-prompt> m4 foo.m4 > foo

and try to translate it into

<exec executable="m4">
  <arg value="foo.m4"/>
  <arg value="&gt;"/>
  <arg value="foo"/>
</exec>

This will not do what you expect. The output redirection is performed by your shell, not the command itself, so this should read:

<exec executable="/bin/sh">
  <arg value="-c" />
  <arg value="m4 foo.m4 &gt; foo" />
</exec>

Note that you must use the value attribute of <arg> in the last element, in order to have the command passed as a single, quoted argument. Alternatively, you can use:

<exec executable="/bin/sh">
  <arg line='-c "m4 foo.m4 &gt; foo"'/>
</exec>

Note the double-quotes nested inside the single-quotes.

m4 コマンドの標準出力を、次のようにファイルにリダイレクトしたいとしましょう:

プロンプト> m4 foo.m4 > foo

それを次のように書き換えたとします:

<exec executable="m4">
  <arg value="foo.m4"/>
  <arg value="&gt;"/>
  <arg value="foo"/>
</exec>

しかしこれでは、期待したようには動作しません。 出力のリダイレクトはコマンド自身ではなく、シェルが行っているからです。 そこで、次のようにします:

<exec executable="/bin/sh">
  <arg value="-c" />
  <arg value="m4 foo.m4 &gt; foo" />
</exec>

シングルクォートされた引数としてコマンドに渡すために、 最後の要素において、 <arg>value属性を使わなければならないことにも注意してください。 別の方法として、次のようにもできます:

<exec executable="/bin/sh">
  <arg line='-c "m4 foo.m4 &gt; foo"'/>
</exec>

シングルクォート中のネストされたダブルクォートに注意してください。

How do I execute a batch file or shell script from Ant? − Ant からバッチファイルやシェルスクリプトを実行するにはどうすればいいですか?

On native Unix systems, you should be able to run shell scripts directly. On systems running a Unix-type shell (for example, Cygwin on Windows) execute the (command) shell instead - cmd for batch files, sh for shell scripts - then pass the batch file or shell script (plus any arguments to the script) as a single command, using the /c or -c switch, respectively. See the above section for example <exec> tasks executing sh. For batch files, use something like:

<exec dir="." executable="cmd" os="Windows NT">
  <arg line="/c test.bat"/>
</exec>

Unix システム上では、シェルスクリプトを直接実行できます。 Unix形式のシェル(例えば Windows 上の Cygwin )を実行するシステムでは、 代わりに(コマンド)シェル ―― バッチファイルの場合はcmd、 シェルスクリプトの場合にはsh ―― を実行し、 /c または -c スイッチを用いて、 バッチファイルやシェルスクリプト (およびスクリプトの引数) を一つのコマンドとして渡します。 上の節shを実行する <exec>タスクの例を説明しています。 バッチファイルの場合、次のように使います:

<exec dir="." executable="cmd" os="Windows NT">
  <arg line="/c test.bat"/>
</exec>

I want to execute a particular target only if multiple conditions are true. − 複数の条件が true になった時のみ、特定のターゲットを実行したいのですが?

There are actually several answers to this question.

If you have only one set and one unset property to test, you can specify both an if and an unless attribute for the target, and they will act as if they are "anded" together.

If you are using a version of Ant 1.3 or earlier, the way to work with all other cases is to chain targets together to determine the specific state you want to test for.

To see how this works, assume you have three properties: prop1, prop2, and prop3. You want to test that prop1 and prop2 are set, and that prop3 is not. If the condition holds true you want to echo "yes".

Here is the implementation in Ant 1.3 and earlier:

<target name="cond" depends="cond-if"/>

<target name="cond-if" if="prop1">
  <antcall target="cond-if-2"/>
</target>

<target name="cond-if-2" if="prop2">
  <antcall target="cond-if-3"/>
</target>

<target name="cond-if-3" unless="prop3">
  <echo message="yes"/>
</target>

Note: <antcall> tasks do not pass property changes back up to the environment they were called from, so you would'nt be able to, for example, set a result property in the cond-if-3 target, then do <echo message="result is ${result}"/> in the cond target.

Starting with Ant 1.4, you can use the <condition> task.

<target name="cond" depends="cond-if,cond-else"/>

<target name="check-cond">
  <condition property="cond-is-true">
    <and>
      <not>
        <equals arg1="${prop1}" arg2="$${prop1}" />
      </not>
      <not>
        <equals arg1="${prop2}" arg2="$${prop2}" />
      </not>
      <equals arg1="${prop3}" arg2="$${prop3}" />
    </and>
  </condition>
</target>

<target name="cond-if" depends="check-cond" if="cond-is-true">
  <echo message="yes"/>
</target>

<target name="cond-else" depends="check-cond" unless="cond-is-true">
  <echo message="no"/>
</target>

This version takes advantage of two things:

  • If a property a has not been set, ${a} will evaluate to ${a}.
  • To get a literal $ in Ant, you have to escape it with another $ - this will also break the special treatment of the ${ sequence.

Because testing for a literal ${property} string isn't all that readable or easy to understand, post-1.4.1 Ant introduces the <isset> element to the <condition> task.

Here is the previous example done using <isset>:

<target name="check-cond">
  <condition property="cond-is-true">
    <and>
      <isset property="prop1"/>
      <isset property="prop2"/>
      <not>
        <isset property="prop3"/>
      </not>
    </and>
  </condition>
</target>

The last option is to use a scripting language to set the properties. This can be particularly handy when you need much finer control than the simple conditions shown here but, of course, comes with the overhead of adding JAR files to support the language, to say nothing of the added maintenance in requiring two languages to implement a single system. See the <script> task documentation for more details.

実に、この質問には幾つかの回答があります。

必要なプロパティ、不要なプロパティがそれぞれ一つだけしかないなら、 ターゲットに対して、ifunless 属性を一緒に指定すれば、 それらの "AND" がとられます。

Ant 1.3 以前を使っている場合は、 各条件を判定するターゲットを連鎖させることで実現できます。

prop1prop2prop3 という 3つのプロパティを想定して、どのように動作するのか見てみましょう。 prop1prop2 が設定されていて、かつ prop3 が設定されていない、という条件が真である時、 "yes"と出力したいとします。

Ant 1.3 以前では、以下のように実装します:

<target name="cond" depends="cond-if"/>

<target name="cond-if" if="prop1">
  <antcall target="cond-if-2"/>
</target>

<target name="cond-if-2" if="prop2">
  <antcall target="cond-if-3"/>
</target>

<target name="cond-if-3" unless="prop3">
  <echo message="yes"/>
</target>

注意: <antcall> タスクは、 タスクが呼ばれた環境をバックアップして、 プロパティの変更を渡すことはしない 点に注意してください。 つまり、例えば、 まず cond-if-3 ターゲット内で result プロパティをセットしておいてから cond ターゲットで <echo message="result is ${result}"/> を行う、 といったことはできません。

Ant 1.4 からは、<condition> タスクが使えます。

<target name="cond" depends="cond-if,cond-else"/>

<target name="check-cond">
  <condition property="cond-is-true">
    <and>
      <not>
        <equals arg1="${prop1}" arg2="$${prop1}" />
      </not>
      <not>
        <equals arg1="${prop2}" arg2="$${prop2}" />
      </not>
      <equals arg1="${prop3}" arg2="$${prop3}" />
    </and>
  </condition>
</target>

<target name="cond-if" depends="check-cond" if="cond-is-true">
  <echo message="yes"/>
</target>

<target name="cond-else" depends="check-cond" unless="cond-is-true">
  <echo message="no"/>
</target>

この方法には2つの利点があります:

条件判断のための ${property}というリテラル文字列は あまり読みやすくなく、理解しやすくないので、 Ant 1.4.1 から、<condition>タスクで <isset> 要素が使えるようになっています。

前述の例を、<isset>を使って書き換えると、以下のようになります:

<target name="check-cond">
  <condition property="cond-is-true">
    <and>
      <isset property="prop1"/>
      <isset property="prop2"/>
      <not>
        <isset property="prop3"/>
      </not>
    </and>
  </condition>
</target>

最後の選択肢は、プロパティを設定するためにスクリプト言語を使う、という方法です。 ここで示したような簡単な条件文より、さらに細かい制御が必要な場合には、特に便利でしょう。 しかし、もちろん、その言語をサポートする JAR ファイルを加えることによるオーバーヘッドが生じますし、 一つのシステムを実装するのに2つの言語が必要とする保守の問題があることは言うまでもありません。 これについて、詳しくは <script>タスクのドキュメント をご覧ください。

How can I include national characters like German umlauts in my build file? − ドイツ語のウムラウトといったような、自国の文字をビルドファイルに含めるにはどうすればいいですか?

You need to tell the XML parser which character encoding your build file uses, this is done inside the XML declaration.

By default the parser assumes you are using the UTF-8 encoding instead of your platform's default. For most Western European countries you should set the encoding to ISO-8859-1. To do so, make the very first line of you build file read like

<?xml version="1.0" encoding="ISO-8859-1" ?>

ビルドファイルで使っている文字エンコーディングを、 XML 宣言に記述して XMLパーサに伝えてやる必要があります。

パーサはデフォルトでは、プラットフォームのデフォルトではなく、UTF-8 エンコーディングを想定して動作します。 西ヨーロッパ諸国では、ISO-8859-1 を指定すべきです。 そうするには、ビルドファイルの一番最初で以下のように記述します:

<?xml version="1.0" encoding="ISO-8859-1" ?>

[訳注: 日本語を記述する場合は、文字エンコーディングとして UTF-8 を用いるのがよいでしょう。 あるいは、たとえばJISエンコーディングを用いている場合は、以下のように記述します]

<?xml version="1.0" encoding="ISO-2022-JP" ?>

How do I use jar's M switch? I don't want a MANIFEST.? − MANIFESTは要らないんですが、 jarMスイッチはどうやって使えばいいですか?

A JAR archive is a ZIP file, so if you don't want a MANIFEST you can simply use <zip>.

If your file names contain national characters you should know that Sun's jar utility like Ant's <jar> uses UFT8 to encode their names while <zip> uses your platforms default encoding. Use the encoding attribute of <zip> if necessary.

JARアーカイブはZIPファイルなので、MANIFESTが要らないなら、 単純に <zip>を使えばよいです。

ファイル名に自国の文字が入っている場合、 Sunの jarユーティリティは Ant の<jar> と同様に、 UTF-8 を使ってファイル名をエンコードし、 <zip>はプラットフォームデフォルトエンコーディングを使用する、 ということを知っておく必要があります。 必要なら、<zip>の encoding 属性を使用します。

How can I do something like <property name="prop" value="${${anotherprop}}"/> (double expanding the property)? − <property name="prop" value="${${anotherprop}}"/> のように、 プロパティを二回展開するにはどうすればいいですか?

Without any external help you can not.

With <script/>, which needs external libraries, you can do

<script language="javascript">
    propname = project.getProperty("anotherprop");
    project.setNewProperty("prop", propname);
</script>

With AntContrib (external task library) you can do <propertycopy name="prop" from="${anotherprop}"/>.

Ant単体では実現できません。

外部ライブラリを使う <script> を使えば、以下のように実現できます

<script language="javascript">
    propname = project.getProperty("anotherprop");
    project.setNewProperty("prop", propname);
</script>

AntContrib (拡張タスクライブラリ) を使えば、 <propertycopy name="prop" from="${anotherprop}"/> のように実現できます。

Why does Ant always recompile all my Java files? − なぜ Ant は常に 私の Java ファイルを再コンパイルするのですか?

In order to find out which files should be compiled, Ant compares the timestamps of the source files to those of the resulting .class files. Opening all source files to find out which package they belong to would be very inefficient. Instead, Ant expects you to place your source files in a directory hierarchy that mirrors your package hierarchy and to point Ant to the root of this directory tree with the srcdir attribute.

Say you have <javac srcdir="src" destdir="dest"/>. If Ant finds a file src/a/b/C.java, it expects it to be in package a.b so that the resulting .class file is going to be dest/a/b/C.class.

If your source-tree directory structure does not match your package structure, Ant's heuristic won't work, and it will recompile classes that are up-to-date. Ant is not the only tool that expects a source-tree layout like this.

If you have Java source files that aren't declared to be part of any package, you can still use the <javac> task to compile these files correctly - just set the srcdir and destdir attributes to the actual directory the source files live in and the directory the class files should go into, respectively.

どのファイルをコンパイルすべきか調べるするために、 Ant は、 ソースファイルと、その結果となる.classファイルのタイムスタンプを比較しています。 ソースがどのパッケージに属しているか調べるために全てのソースファイルを開くことは大変非効率です。 その代わりに、Ant では、 srcdir属性で指定したディレクトリを基点とした、 パッケージ階層を反映したディレクトリ階層に、 ソースファイルが置かれている、という前提で動作しています。

たとえば、<javac srcdir="src" destdir="dest"/>では、 Ant はファイル src/a/b/C.java を見つけると、 そのファイルはパッケージa.bにあり、 結果の .class ファイルは、 dest/a/b/C.class に置かれる、と推測します。

ソースツリーのディレクトリ構造がパッケージの構造と一致していない場合、 Ant のヒューリステックは動作せず、最新であるクラスでも再コンパイルしてしまいます。 Ant はこのようなソースツリーの配置を想定する唯一のツールではありません。

どのパッケージにも属すさない Java ソースファイルがある場合でも、 これらのファイルを正しくコンパイルするために <javac>タスクが使えます ―― srcdir および destdir属性を ソースファイルのある場所とクラスファイルが出力される場所にそれぞれ設定するだけでよいのです。

I've used a <delete> task to delete unwanted SourceSafe control files (CVS files, editor backup files, etc.), but it doesn't seem to work; the files never get deleted. What's wrong? − 不要な SourceSafe コントロールファイル (CVSファイル、エディタのバックアップファイルなど)を削除するために <delete>タスクを使いましたが、 動作しないようです; ファイルは削除されません。何が悪いのでしょう?

This is probably happening because, by default, Ant excludes SourceSafe control files (vssver.scc) and certain other files from FileSets.

Here's what you probably did:

<delete>
  <fileset dir="${build.src}" includes="**/vssver.scc"/>
</delete>

You need to switch off the default exclusions, and it will work:

<delete>
  <fileset dir="${build.src}" includes="**/vssver.scc"
           defaultexcludes="no"/>
</delete>

For a complete listing of the patterns that are excluded by default, see the user manual.

これはおそらく、Ant がデフォルトで、 SourceSafe の制御ファイル (vssver.scc)や、ある種の他のファイルを、 ファイルセットから除外してしまうために起こります。

おそらくこのようにしたのでしょう:

<delete>
  <fileset dir="${build.src}" includes="**/vssver.scc"/>
</delete>

デフォルト除外集合のスイッチをオフにすれば、動くでしょう:

<delete>
  <fileset dir="${build.src}" includes="**/vssver.scc"
           defaultexcludes="no"/>
</delete>

デフォルトで除外されるパターンの全一覧は、 ユーザマニュアルをご覧ください。

I have a target I want to skip if a property is set, so I have unless="property" as an attribute of the target, but all the targets this target depends on are still executed. Why? − あるプロパティが設定された場合にスキップしたいターゲットがあります。 ターゲットの属性に unless="property"を設定したのですが、 このターゲットが依存する全てのターゲットは、まだ実行されます。何故ですか?

The list of dependencies is generated by Ant before any of the targets are run. This allows dependent targets, such as an init target, to set properties that can control the execution of the targets higher in the dependency graph. This is a good thing.

However, when your dependencies break down the higher-level task into several smaller steps, this behaviour becomes counter-intuitive. There are a couple of solutions available:

  1. Put the same condition on each of the dependent targets.
  2. Execute the steps using <antcall>, instead of specifying them inside the depends attribute.

Antが作成する依存関係のリストは、全てのターゲットが実行される前に生成されます。 これにより、init ターゲットのような 依存されるターゲットが、 依存関係グラフで高い位置にあるターゲットの実行をコントロールするプロパティを設定できるようになります。 これはとても便利です。

しかし、自分の依存関係が高いレベルのタスクから、幾つか小さい段階に落ちたとき、 この動作は、直感と異なる振る舞いをします。 これには幾つかの解決法があります:

  1. 個々のターゲットに、それと同じ条件文を書く。
  2. depends属性で条件を指定する代わりに、 <antcall>を使ってステップを実行する

In my <fileset>, I've put in an <exclude> of all files followed by an <include> of just the files I want, but it isn't giving me any files at all. What's wrong? − <fileset>で 全てのファイル <exclude>、 必要なファイルの <include>、という順に設定しましたが、 どのファイルも得られません。何が悪いのでしょう?

The order of the <include> and <exclude> tags within a <fileset> is ignored when the FileSet is created. Instead, all of the <include> elements are processed together, followed by all of the <exclude> elements. This means that the <exclude> elements only apply to the file list produced by the <include> elements.

To get the files you want, focus on just the <include> patterns that would be necessary to get them. If you find you need to trim the list that the <include> elements produce, then use <exclude> elements.

<fileset>中の <include>および <exclude>タグの順序は無視されます。 代わりに、 全ての<include>要素は、 全ての<exclude>要素に続いて一緒に処理されます。 つまり、 <exclude>要素は、 <include>要素で生成されたファイルリストにのみ適用されます。

期待通りにファイルを得たい場合には、まず それを選択するのに必要となる <include>パターンを記述してください。 <include>要素が生成したリストから除外する必要がある場合に <exclude>要素を使ってください。

ant failed to build my program via javac even when I put the needed jars in an external build.properties file and reference them by pathelement or classpath refid.? − 必要なjarを外部build.propertiesファイルに記述して pathelementclasspath refidを指定した状態で antを実行すると、javac できず、ビルドに失敗します。なぜですか?

When ant loads properties from an external file it dosn't touch the value of properties, trailing blanks will not be trimmed for example.

If the value represents a file path, like a jar needed to compile, the task which requires the value, javac for example would fail to compile since it can't find the file due to trailing spaces.

ant が外部ファイルからプロパティを読むとき、 プロパティの値には手を加えません。 たとえば文末の空白を除去したりすることはありません。

コンパイルに必要なjarなどのファイルパスを指定したとき、 javacなど、その値を必要とするタスクは、文末の空白のためにファイルを認識できずに、 実行が失敗することがあります。

Ant creates WAR files with a lower-case web-inf or JAR files with a lower-case meta-inf directory.? − 小文字の web-inf を含むWARファイルや、 小文字のmeta-infを含むJARファイルを作成しますか?

No it doesn't.

You may have seen these lower-case directory names in WinZIP, but WinZIP is trying to be helpful (and fails). If WinZIP encounters a filename that is all upper-case, it assumes it has come from an old DOS box and changes the case to all lower-case for you.

If you extract (or just check) the archive with jar, you will see that the names have the correct case.

With WinZIP (version 8.1 at least), this can be corrected in the configuration. In the Options/Configuration menu, in the View tab, General section, check the "Allow all upper case files names" box. The META-INF and WEB-INF will look correct.

いえいえ、そんなことはありません。

WinZIPで見ると小文字のディレクトリ名が確認できますが、そのディレクトリは展開できません。 WinZipは、全て大文字のファイル名は古いDOSのものとみなし、小文字で表示します。

jarで展開すると、正しい文字で展開されます。

WinZIPの8.1以降では、この動作を設定で調整できます。 Options/Configrationメニュー → Viewタブ → General で、 "Allow all upper case files names" にチェックしてください。 META-INF も WEB-INF も正しく見えるようになります。

Is Ant supported by my IDE/Editor? − 自分の使っている IDE/エディタで Ant はサポートされてますか?

See the section on IDE integration on our External Tools and Tasks page.

外部ツールおよびタスクのページの IDE との統合の節をご覧ください。

Why doesn't (X)Emacs/vi/MacOS X's project builder correctly parse the error messages generated by Ant? − (X)Emacs/vi/MacOS X のプロジェクトビルダーは なぜ Ant により生成されたエラーメッセージを正しくパースしないのですか?

Ant adds a "banner" with the name of the current task in front of all logging messages - and there are no built-in regular expressions in your editor that would account for this.

You can disable this banner by invoking Ant with the -emacs switch. To make Ant autodetect Emacs' compile mode, put this into your .antrc (contributed by Ville Skytt?).

# Detect (X)Emacs compile mode
if [ "$EMACS" = "t" ] ; then
  ANT_ARGS="$ANT_ARGS -emacs"
  ANT_OPTS="$ANT_OPTS -Dbuild.compiler.emacs=true"
fi

Alternatively, you can add the following snippet to your .emacs to make Emacs understand Ant's output.

(require 'compile)
(setq compilation-error-regexp-alist
  (append (list
     ;; works for jikes
     '("^\\s-*\\[[^]]*\\]\\s-*\\(.+\\):\\([0-9]+\\):\\([0-9]+\\):[0-9]+:[0-9]+:" 1 2 3)
     ;; works for javac
     '("^\\s-*\\[[^]]*\\]\\s-*\\(.+\\):\\([0-9]+\\):" 1 2))
  compilation-error-regexp-alist))

Yet another alternative that preserves most of Ant's formatting is to pipe Ant's output through the following Perl script by Dirk-Willem van Gulik:

#!/usr/bin/perl
#
# May 2001 dirkx@apache.org - remove any
# [foo] lines from the output; keeping
# spacing more or less there.
#
$|=1;
while(<STDIN>) {
        if (s/^(\s+)\[(\w+)\]//) {
                if ($2 ne $last) {
                        print "$1\[$2\]";
                        $s = ' ' x length($2);
                } else {
                        print "$1 $s ";
                };
                $last = $2;
        };
        print;
};

Ant では、全てのログメッセージの先頭にカレントタスク名をつけた"バナー"を出力します。 かつ、エディターに組み込みの正規表現式で、これを考慮しているものはありません。

You can disable this banner by invoking Ant with the -emacs switch. To make Ant autodetect Emacs' compile mode, put this into your .antrc (contributed by Ville Skytt?).

-emacsスイッチをつけて Ant を起動することにより、バナーを無効にできます。 Antに Emacsのコンパイルモードを自動認識させるには、 以下を .antrc に付け加えます( Ville Skytt?による寄贈 )。

# Detect (X)Emacs compile mode
if [ "$EMACS" = "t" ] ; then
  ANT_ARGS="$ANT_ARGS -emacs"
  ANT_OPTS="$ANT_OPTS -Dbuild.compiler.emacs=true"
fi

Alternatively, you can add the following snippet to your .emacs to make Emacs understand Ant's output.

また、Emacs に Ant の出力を理解させるため、 次のコードを .emacsに加えることもできます。

(require 'compile)
(setq compilation-error-regexp-alist
  (append (list
     ;; works for jikes
     '("^\\s-*\\[[^]]*\\]\\s-*\\(.+\\):\\([0-9]+\\):\\([0-9]+\\):[0-9]+:[0-9]+:" 1 2 3)
     ;; works for javac
     '("^\\s-*\\[[^]]*\\]\\s-*\\(.+\\):\\([0-9]+\\):" 1 2))
  compilation-error-regexp-alist))

さらにもう一つの方法として、 Ant のフォーマットの多くを保持するために、 Ant の出力を次の Dirk-Willem van Gulik氏による Perl スクリプトにパイプする方法があります:

#!/usr/bin/perl
#
# May 2001 dirkx@apache.org - remove any
# [foo] lines from the output; keeping
# spacing more or less there.
#
$|=1;
while(<STDIN>) {
        if (s/^(\s+)\[(\w+)\]//) {
                if ($2 ne $last) {
                        print "$1\[$2\]";
                        $s = ' ' x length($2);
                } else {
                        print "$1 $s ";
                };
                $last = $2;
        };
        print;
};

Is there a DTD that I can use to validate my build files? − ビルドファイルを検証できる DTD はありますか?

An incomplete DTD can be created by the <antstructure> task - but this one has a few problems:

  • It doesn't know about required attributes. Only manual tweaking of this file can help here.
  • It is not complete - if you add new tasks via <taskdef> it won't know about it. See this page by Michel Casabianca for a solution to this problem. Note that the DTD you can download at this page is based on Ant 0.3.1.
  • It may even be an invalid DTD. As Ant allows tasks writers to define arbitrary elements, name collisions will happen quite frequently - if your version of Ant contains the optional <test> and <junit> tasks, there are two XML elements named test (the task and the nested child element of <junit>) with different attribute lists. This problem cannot be solved; DTDs don't give a syntax rich enough to support this.

<antstructure>タスクで、不完全ながら DTD は作成可能です。 しかしながら、このDTDには幾つかの問題があります:

How do I include an XML snippet in my build file? − 自分のビルドファイルに XML の一部を含めるにはどうすればいいですか?

You can use XML's way of including external files and let the parser do the job for Ant:

<?xml version="1.0"?>

<!DOCTYPE project [
    <!ENTITY common SYSTEM "file:./common.xml">
]>

<project name="test" default="test" basedir=".">

  <target name="setup">
    ...
  </target>

  &common;

  ...

</project>

will literally include the contents of common.xml where you've placed the &common; entity.

In combination with a DTD, this would look like this:

<!DOCTYPE project PUBLIC "-//ANT//DTD project//EN" "file:./ant.dtd" [
   <!ENTITY include SYSTEM "file:./header.xml">
]>

Starting with Ant 1.6, there is a new <import> task that can (also) be used to include build file fragments. Unlike the snippets used with entity includes, the referenced files have to be complete Ant build files, though.

The example above would become:

<?xml version="1.0"?>
<project name="test" default="test" basedir=".">

  <target name="setup">
    ...
  </target>

  <import file="./common.xml"/>

  ...

</project>

Unlike entity includes, <import> will let you use Ant properties in the file name.

XML における、外部ファイルをインクルードする方法を使えば、パーサが適切に処理します:

<?xml version="1.0"?>

<!DOCTYPE project [
    <!ENTITY common SYSTEM "file:./common.xml">
]>

<project name="test" default="test" basedir=".">

  <target name="setup">
    ...
  </target>

  &common;

  ...

</project>

この例では、 &common;実体参照の場所に、 common.xmlの内容をそのままインクルードします。

DTD と併用する場合、次のようになります:

<!DOCTYPE project PUBLIC "-//ANT//DTD project//EN" "file:./ant.dtd" [
   <!ENTITY include SYSTEM "file:./header.xml">
]>

Ant 1.6以降では、<import>タスクで、 ビルドファイルの断片をインクルードできます。 実体参照でのインクルードとは異なり、参照先のファイルは完全なAntビルドファイルである必要があります。

この例は以下のようになります:

<?xml version="1.0"?>
<project name="test" default="test" basedir=".">

  <target name="setup">
    ...
  </target>

  <import file="./common.xml"/>

  ...

</project>

実体参照のインクルードとは異なり、 <import> は ファイル名にプロパティを使用できます。

How do I send an email with the result of my build process? − ビルドの処理結果をメールで送るにはどうすればいいですか?

If you are using a nightly build of Ant 1.5 after 2001-12-14, you can use the built-in MailLogger:

         ant -logger org.apache.tools.ant.listener.MailLogger

See the Listeners & Loggers documentation for details on the properties required.

For older versions of Ant, you can use a custom BuildListener that sends out an email in the buildFinished() method. Will Glozer <will.glozer@jda.com> has written such a listener based on JavaMail. The source is:

import java.io.*;
import java.util.*;
import javax.mail.*;
import javax.mail.internet.*;
import org.apache.tools.ant.*;

/**
 * A simple listener that waits for a build to finish and sends an email
 * of the results.  The settings are stored in "monitor.properties" and
 * are fairly self explanatory.
 *
 * @author      Will Glozer
 * @version     1.05a 09/06/2000
 */
public class BuildMonitor implements BuildListener {
    protected Properties props;

    /**
     * Create a new BuildMonitor.
     */
    public BuildMonitor() throws Exception {
        props = new Properties();
        InputStream is = getClass().getResourceAsStream("monitor.properties");
        props.load(is);
        is.close();
    }

    public void buildStarted(BuildEvent e) {
    }

    /**
     * Determine the status of the build and the actions to follow, now that
     * the build has completed.
     *
     * @param       e       Event describing the build status.
     */
    public void buildFinished(BuildEvent e) {
        Throwable th = e.getException();
        String status = (th != null) ? "failed" : "succeeded";

        try {
            String key = "build." + status;
            if (props.getProperty(key + ".notify").equalsIgnoreCase("false")) {
                    return;
            }

            Session session = Session.getDefaultInstance(props, null);

            MimeMessage message = new MimeMessage(session);
            message.addRecipients(Message.RecipientType.TO, parseAddresses(
                props.getProperty(key + ".email.to")));
            message.setSubject(props.getProperty(key + ".email.subject"));

            BufferedReader br = new BufferedReader(new FileReader(
                props.getProperty("build.log")));
            StringWriter sw = new StringWriter();

            String line = br.readLine();
            while (line != null) {
                sw.write(line);
                sw.write("\n");
                line = br.readLine();
            }
            br.close();

            message.setText(sw.toString(), "UTF-8");
            sw.close();

            Transport transport = session.getTransport();
            transport.connect();
            transport.send(message);
            transport.close();
        } catch (Exception ex) {
            System.out.println("BuildMonitor failed to send email!");
            ex.printStackTrace();
        }
    }

    /**
     * Parse a comma separated list of internet email addresses.
     *
     * @param       s       The list of addresses.
     * @return      Array of Addresses.
     */
    protected Address[] parseAddresses(String s) throws Exception {
        StringTokenizer st = new StringTokenizer(s, ",");
        Address[] addrs = new Address[st.countTokens()];

        for (int i = 0; i < addrs.length; i++) {
            addrs[i] = new InternetAddress(st.nextToken());
        }
        return addrs;
    }

    public void messageLogged(BuildEvent e) {
    }

    public void targetStarted(BuildEvent e) {
    }

    public void targetFinished(BuildEvent e) {
    }

    public void taskStarted(BuildEvent e) {
    }

    public void taskFinished(BuildEvent e) {
    }
}

With a monitor.properties like this:

# configuration for build monitor

mail.transport.protocol=smtp
mail.smtp.host=<host>
mail.from=Will Glozer <will.glozer@jda.com>

build.log=build.log

build.failed.notify=true
build.failed.email.to=will.glozer@jda.com
build.failed.email.subject=Nightly build failed!

build.succeeded.notify=true
build.succeeded.email.to=will.glozer@jda.com
build.succeeded.email.subject=Nightly build succeeded!

monitor.properties should be placed right next to your compiled BuildMonitor.class. To use it, invoke Ant like:

ant -listener BuildMonitor -logfile build.log

Make sure that mail.jar from JavaMail and activation.jar from the Java Beans Activation Framework are in your CLASSPATH.

Ant 1.5 の 2001-12-14付ナイトビルド以降であれば、 組み込みのMailLoggerが使えます:

         ant -logger org.apache.tools.ant.listener.MailLogger

必要なプロパティについての詳細は、 リスナーとロガー のドキュメントをご覧ください。

古いAntでは、buildFinished() メソッドでメールを送信するような カスタムBuildListenerを使って実現できます。 Will Glozer 氏 <will.glozer@jda.com> が、そのような JavaMail を使ったリスナーを開発してくれました。 ソースは次のとおりです:

import java.io.*;
import java.util.*;
import javax.mail.*;
import javax.mail.internet.*;
import org.apache.tools.ant.*;

/**
 * ビルドが終了するのを待ち、結果をメールで送るシンプルなリスナ。
 * 設定は "monitor.properties" に書く。
 *
 * @author      Will Glozer
 * @version     1.05a 09/06/2000
 */
public class BuildMonitor implements BuildListener {
    protected Properties props;

    /**
     * ビルドモニタを作成する。
     */
    public BuildMonitor() throws Exception {
        props = new Properties();
        InputStream is = getClass().getResourceAsStream("monitor.properties");
        props.load(is);
        is.close();
    }

    public void buildStarted(BuildEvent e) {
    }

    /**
     * ビルドの状態を判断し、次のアクションを決定する。
     * この時点では、ビルドは完了している。
     *
     * @param       e       ビルド状態を保持しているイベント
     */
    public void buildFinished(BuildEvent e) {
        Throwable th = e.getException();
        String status = (th != null) ? "failed" : "succeeded";

        try {
            String key = "build." + status;
            if (props.getProperty(key + ".notify").equalsIgnoreCase("false")) {
                    return;
            }

            Session session = Session.getDefaultInstance(props, null);

            MimeMessage message = new MimeMessage(session);
            message.addRecipients(Message.RecipientType.TO, parseAddresses(
                props.getProperty(key + ".email.to")));
            message.setSubject(props.getProperty(key + ".email.subject"));

            BufferedReader br = new BufferedReader(new FileReader(
                props.getProperty("build.log")));
            StringWriter sw = new StringWriter();

            String line = br.readLine();
            while (line != null) {
                sw.write(line);
                sw.write("\n");
                line = br.readLine();
            }
            br.close();

            message.setText(sw.toString(), "UTF-8");
            sw.close();

            Transport transport = session.getTransport();
            transport.connect();
            transport.send(message);
            transport.close();
        } catch (Exception ex) {
            System.out.println("BuildMonitor failed to send email!");
            ex.printStackTrace();
        }
    }

    /**
     * カンマで区切られたメールアドレスのリストを読み込む。
     *
     * @param       s       アドレスのリスト
     * @return      アドレスの配列
     */
    protected Address[] parseAddresses(String s) throws Exception {
        StringTokenizer st = new StringTokenizer(s, ",");
        Address[] addrs = new Address[st.countTokens()];

        for (int i = 0; i < addrs.length; i++) {
            addrs[i] = new InternetAddress(st.nextToken());
        }
        return addrs;
    }

    public void messageLogged(BuildEvent e) {
    }

    public void targetStarted(BuildEvent e) {
    }

    public void targetFinished(BuildEvent e) {
    }

    public void taskStarted(BuildEvent e) {
    }

    public void taskFinished(BuildEvent e) {
    }
}

使用するmonitor.propertiesは以下のようになります:

# ビルドモニタの設定

mail.transport.protocol=smtp
mail.smtp.host=<host>
mail.from=Will Glozer <will.glozer@jda.com>

build.log=build.log

build.failed.notify=true
build.failed.email.to=will.glozer@jda.com
build.failed.email.subject=Nightly build failed!

build.succeeded.notify=true
build.succeeded.email.to=will.glozer@jda.com
build.succeeded.email.subject=Nightly build succeeded!

monitor.properties ファイルは コンパイルしたBuildMonitor.classと同じ場所に置かれます。 これを使うには Ant を次のように起動します:

ant -listener BuildMonitor -logfile build.log

このとき、忘れずに JavaMail の mail.jar および Java Beans Activation Frameworkactivation.jarCLASSPATH上に配置してください。

How do I get at the properties that Ant was running with from inside BuildListener? − Ant 動作後のプロパティの値を BuildListener で取得するにはどうすればいいですか?

You can get at a hashtable with all the properties that Ant has been using through the BuildEvent parameter. For example:

public void buildFinished(BuildEvent e) {
    Hashtable table = e.getProject().getProperties();
    String buildpath = (String)table.get("build.path");
    ...
}

This is more accurate than just reading the same property files that your project does, since it will give the correct results for properties that were specified on the Ant command line.

Ant が使用している全てのプロパティが格納されたハッシュテーブルを、 BuildEventパラメータから取り出すことができます。たとえば以下のようになります:

public void buildFinished(BuildEvent e) {
    Hashtable table = e.getProject().getProperties();
    String buildpath = (String)table.get("build.path");
    ...
}

この方法は、 コマンドラインで指定されたプロパティ値も取り出せるぶん、 同じプロパティファイルを独自に読み込むよりも正確です。

<chmod> or <exec> doesn't work in Ant 1.3 on Unix? − Unix 上の Ant 1.3 で <chmod> や <exec>が動かないのですが?

The antRun script in ANT_HOME/bin has DOS instead of Unix line endings; you must remove the carriage-return characters from this file. This can be done by using Ant's <fixcrlf> task or something like:

tr -d '\r' < $ANT_HOME/bin/antRun > /tmp/foo
mv /tmp/foo $ANT_HOME/bin/antRun

ANT_HOME/binにあるantRunスクリプトは、 Unix でなく DOS の行末文字になっているので、 このファイルから改行文字(CR)を取り除く必要があります。 それには、Ant の<fixcrlf>タスクを使うか、次のようにします:

tr -d '\r' < $ANT_HOME/bin/antRun > /tmp/foo
mv /tmp/foo $ANT_HOME/bin/antRun

JavaDoc failed: java.io.IOException: javadoc: cannot execute? − JavaDocを実行しようとすると、java.io.IOException: javadoc: cannot execute というエラーがでて実行できません。

There is a bug in the Solaris reference implementation of the JDK (see http://developer.java.sun.com/developer/bugParade/bugs/4230399.html). This also appears to be true under Linux. Moving the JDK to the front of the PATH fixes the problem.

これは、JDK のSolaris 用リファレンス実装のバグです (http://developer.java.sun.com/developer/bugParade/bugs/4230399.htmlをご覧ください)。 これは Linux 上でも発生します。JDK を PATH の先頭に移動すれば、問題は解決します。

<style> or <junit> ignores my <classpath>? − <style> や <junit> は、<classpath>設定を無視していませんか?

These tasks don't ignore your classpath setting, you are facing a common problem with delegating classloaders.

First of all let's state that Ant adds all .jar files from ANT_HOME/lib to CLASSPATH, therefore "in CLASSPATH" shall mean "either in your CLASSPATH environment variable or ANT_HOME/lib" for the rest of this answer.

Technically the sentence above isn't true for Ant 1.6 and later anymore, but the result is the same. For the sake of this discussion, CLASSPATH and ANT_HOME/lib are identical.

This question collects a common type of problem: A task needs an external library and it has a nested classpath element so that you can point it to this external library, but that doesn't work unless you put the external library into the CLASSPATH.

The root of the problem is that the class that needs the external library is on the CLASSPATH.

When you specify a nested <classpath> in Ant, Ant creates a new class loader that uses the path you have specified. It then tries to load additional classes from this classloader.

In most cases - for example the two cases above - Ant doesn't load the external library directly, it is the loaded class that does so.

In the case of <junit> it is the task implementation itself and in the case of <style> it is the implementation of the org.apache.tools.ant.taskdefs.XSLTLiaison class.

Ant's class loader implementation uses Java's delegation model, see http://java.sun.com/products/jdk/1.2/docs/api/java/lang/ClassLoader.html the paragraph

The ClassLoader class uses a delegation model to search for classes and resources. Each instance of ClassLoader has an associated parent class loader. When called upon to find a class or resource, a ClassLoader instance will delegate the search for the class or resource to its parent class loader before attempting to find the class or resource itself. The virtual machine's built-in class loader, called the bootstrap class loader, does not itself have a parent but may serve as the parent of a ClassLoader instance.

This means, Ant's class loader will consult the bootstrap class loader first, which tries to load classes from CLASSPATH. The bootstrap class loader doesn't know anything about Ant's class loader or even the path you have specified.

If the bootstrap class loader can load the class Ant has asked it to load, this class will try to load the external library from CLASSPATH as well - it doesn't know anything else - and will not find it unless the library is in CLASSPATH as well.

To solve this, you have two major options:

  1. put all external libraries you need in CLASSPATH as well this is not what you want, otherwise you wouldn't have found this FAQ entry.
  2. remove the class that loads the external library from the CLASSPATH.

Using The Second Option with Ant 1.5.4 and Earlier:

The easiest way to do this is to remove optional.jar from ANT_HOME/lib. If you do so, you will have to <taskdef> all optional tasks and use nested <classpath> elements in the <taskdef> tasks that point to the new location of optional.jar. Also, don't forget to add the new location of optional.jar to the <classpath> of your <style> or <junit> task.

If you want to avoid to <taskdef> all optional tasks you need, the only other option is to remove the classes that should not be loaded via the bootstrap class loader from optional.jar and put them into a separate archive. Add this separate archive to the <classpath> of your <style> or <junit> task - and make sure the separate archive is not in CLASSPATH.

In the case of <junit> you'd have to remove all classes that are in the org/apache/tools/ant/taskdefs/optional/junit directory, in the <style> case it is one of the *Liaison classes in org/apache/tools/ant/taskdefs/optional.

Using The Second Option with Ant 1.6 and later:

In Ant 1.6 optional.jar has been split into multiple jars, each one containing classes with the same dependencies on external libraries. You can move the "offending" jar out of ANT_HOME/lib. For the <junit> task it would be ant-junit.jar and for <style> it would be ant-trax.jar, ant-xalan1.jar or ant-xslp.jar - depending on the processor you use.

If you use the option to break up optional.jar for <junit> or remove ant-junit.jar, you still have to use a <taskdef> with a nested <classpath> to define the junit task.

これらのタスクはクラスパスの設定を無視していませんが、 クラスローダの委譲に起因する共通の問題に直面しています。

Antは ANT_HOME/libにある.jar ファイル全てを CLASSPATH に追加します。したがって、 「CLASSPATH中にある」とは、 「CLASSPATH環境変数、またはANT_HOME/libにある」ということを意味します。

厳密に言えば、上記は Ant 1.6 以降では正しくありませんが、結果は同じなので、 この説明の中では CLASSPATHANT_HOME/libは同じものとして扱います。

この質問は、共通の問題を集めています。すなわち、 「タスクが外部ライブラリを必要とする場合、 その外部ライブラリは classpath 要素 で指定するのではだめで、 CLASSPATHに置かないと動作しない」という問題です。

問題の根本は、外部ライブラリを必要とするクラスが CLASSPATH上にある、ということです。

<classpath>内部要素を指定したとき、 Ant はそのパスを使用する新しいクラスローダを生成し、 そのクラスローダを用いて追加クラスのロードを試みます。

前述した 2 つのケースを始め、ほとんどの場合で、 外部ライブラリは直接ではなく、上記のようにロードされたものです。

<junit> の場合では、タスクのクラスが、 <style>の場合では、org.apache.tools.ant.taskdefs.XSLTLiaison クラスが、 CLASSPATHからロードされるクラスです。

Ant のクラスローダの実装は Java のデリゲートモデルを使用しています。 http://java.sun.com/products/jdk/1.2/docs/api/java/lang/ClassLoader.htmlの節を見ると、

ClassLoader クラスは、委譲モデルを使ってクラスとリソースを探します。 ClassLoader の各インスタンスは、関連する親クラスローダを持ちます。 クラスまたはリソースを見つけるために呼び出されると、 ClassLoader インスタンスはそれ自体でクラスまたはリソースの検索を試みる前に、 その検索を親クラスに委譲します。 ブートストラップクラスローダと呼ばれる仮想マシンの組み込みクラスローダはそれ自体では親を持たず、 ClassLoader インスタンスの親として動作します。

つまり、Ant のクラスローダはまずブートストラップクラスローダに問い合わせ、 CLASSPATHから、クラスのロードを試みます。 ブートストラップクラスローダは Ant のクラスローダについては何も情報を持たず、 classpath内部要素で指定したパスももちろん知りません。

Antが問い合わせたクラスをブートストラップクラスローダがロードできる場合、 そのクラスは同様に、外部ライブラリを CLASSPATH からロードしようとします。 しかし、その外部ライブラリが CLASSPATHになければ、見つけることができません。

この問題を解決するには、大きく二つのやり方があります:

  1. 必要な外部ライブラリを全てCLASSPATH に置く。 これは、望んでいる方法ではないでしょう。 そうでなきゃこのFAQ項目など読んでいないでしょう。
  2. 外部ライブラリをロードするクラスをCLASSPATHから削除する。

Ant 1.5.4 以前では:

これを解決するもっとも簡単な方法は、ANT_HOME/lib から optional.jar を取り除いてしまうことです。 そうした場合、使いたい全てのオプションタスクを、 <taskdef> し、かつ、それに <classpath>内部要素で optional.jarの場所を指定してやる必要があります。さらに、 <style><junit> にも忘れずに <classpath>optional.jar の場所を指定してやる必要があります。

そんなことしたくない、という場合の、唯一のもう一つの方法は、 ブートストラップクラスローダにロードされるべきでないクラスを optional.jar から削除し、 それらを別のアーカイブに入れ、それを <style><junit> タスクの<classpath>に加えます。―― その別のアーカイブは CLASSPATH から参照できないようにしてください。

<junit>の場合で言えば、 org/apache/tools/ant/taskdefs/optional/junit ディレクトリのクラスを全て削除します。 <style>の場合で言えば、 org/apache/tools/ant/taskdefs/optional にある *Liaison クラスを削除します。

Ant 1.6 以降では:

Ant 1.6では、optional.jar はすでに、 外部ライブラリへの依存性が同じである単位で複数jarファイルに分割されており、 動作不良を引き起こす jar を ANT_HOME/lib 以外へ移動することができるようになっています。 <junit>タスクは ant-junit.jar<style>タスクは ant-trax.jarと、 使用しているプロセッサに応じてant-xalan1.jarまたはant-xslp.jar がそれに相当します。

いずれにしろ、<junit>のために optional.jarを分割する、または ant-junit.jarを移動する、 という方法をとっているなら、 <classpath>内部要素を持つ <taskdef>を使って junit タスクを定義する必要があります。

When running Ant 1.4 on Windows XP and JDK 1.4, I get various errors when trying to <exec>, fork <java> or access environment variables.? − WindowsXP上のJDK1.4でAnt1.4を実行すると、 <exec>の実行、 <java>プロセスの生成、環境変数を参照するとき、さまざまなエラーが出ます。 どうしたらいいでしょう?

Ant < 1.5 doesn't recognize Windows XP as a flavor of Windows that runs CMD.EXE instead of COMMAND.COM. JDK 1.3 will tell Ant that Windows XP is Windows 2000 so the problem doesn't show up there.

Apart from upgrading to Ant 1.5 or better, setting the environment variable ANT_OPTS to -Dos.name=Windows_NT prior to invoking Ant has been confirmed as a workaround.

Ant の 1.5 以前では、COMMAND.COM ではなく CMD.EXE を使っているWindowsXPを、Windows系とは解釈していません。 JDK1.3上ではWindowsXPは Windows2000と同じものだとAntが解釈しているため、問題ありません。

Ant 1.5以上を用いる、という以外には、ANT_OPTS環境変数に -Dos.NAME=Windows_NT と設定した上でAntを実行する、という回避方法があります。

The ant wrapper script of Ant 1.5 fails for Cygwin if ANT_HOME is set to a Windows style path.? − Antの1.5で、ANT_HOME を Windows形式のパスで設定しているとき、 Cygwin環境で antラッパースクリプトが動作しませんが?

This problem has been reported only hours after Ant 1.5 has been released, see Bug 10664 and all its duplicates.

A fixed version of the wrapper script can be found here. Simply replace your script with this version.

この問題はAnt1.5のリリース直後に報告されました。 Bug 10664 とその関連報告をご覧ください。

ここ に修正版ラッパースクリプトがあるので、これに置き換えてください。

<zip> is broken in Ant 1.5.2.? − Ant 1.5.2 の <zip> は壊れていませんか?

Yes, it is.

The problem reported by most people - see Bug 17648 and all its duplicates - is that Ant creates archives that a partially unreadable by WinZIP. Luckily jar deals with the archives and so the generated jars/wars/ears will most likely work for you anyway.

There are additional problems, see bugs Bug 17780, Bug 17871 and Bug 18403. All of them are supposed to be fixed with Ant 1.5.3 (and only 18403 should exist in 1.5.3beta1).

YES、そのとおりです。

この問題はたくさん報告されました (Bug 17648 と関連報告)。 Antが、一部分がWinZIPでは一部分を読み込めないアーカイブファイルを作成してしまう、というものです。 幸い、そのアーカイブは、jar を使えば展開できるので、jar/war/ear を生成した場合はきちんと動作します。

さらにいろいろな問題が報告されています: Bug 17780, Bug 17871, Bug 18403 を見てください。これらは Ant 1.5.3 で解決されています。

Why do my custom task containers see Unknown Elements in Ant 1.6 - they worked in Ant 1.5? ? − Ant 1.5 で動作していたカスタムタスクコンテナが、Ant 1.6 では、未知要素に出くわしてしまいます。 なぜですか?

The objects added in TaskContainer.addTask(Task task) have changed from Tasks to UnknownElements.

There was a number of valid reasons for this change. But the backward compatibility problems were not noticed until after Ant 1.6.0 was released.

Your container class will need to be modified to check if the Task is an UnknownElement and call perform on it to convert it to a Task and to execute it. (see apache.tools.ant.taskdefs.Sequential)

If you want to do more processing on the task, you need to use the techniques in apache.tools.ant.taskdefs.Antlib#execute() This does make use of one 1.6 method call (UE#getRealObject()), you need to use UE#getTask() instead - this will return null for non tasks (types like fileset id=x).

So.. iterate over the tasks, if they are UEs, convert them to tasks, using UE#maybeConfigure and UE#getTask()

        for (Iterator i = tasks.iterator(); i.hasNext();) {
           Task t = (Task) i.next();
           if (t instanceof UnknownElement) {
              ((UnknownElement) t).maybeConfigure();
              t = ((UnknownElement) t).getTask();
              if (t == null) {
                  continue;
              }
           }
           // .... original Custom code
        }
        

This approach should work for ant1.5 and ant1.6.

TaskContainer.addTask(Task task) 内で追加されたオブジェクトは、 Task から UnknownElements に変更されました。

この変更には、さまざまな理由があります。Ant 1.6.0 がリリースされたとき、 この下位互換性の問題は通知されていませんでした。

タスクがUnknownElementであるかチェックして、 必要に応じて perform を呼び出してタスクに変換してから実行するように、 コンテナクラスの実装を修正する必要があります (apache.tools.ant.taskdefs.Sequential 参照)。

そのタスクでさらに処理を行いたいなら、 apache.tools.ant.taskdefs.Antlib#execute() で使っているテクニックを使う必要があります。 これは 1.6のメソッドを(UE#getRealObject())を呼び出していますが、 代わりに UE#getTask() を使う必要があります (getTask()は、fileset id=x のような、タスクではないものについて null を返します)。

要するに…… タスクを順番に処理し、それがUEだったら UE#maybeConfigure と UE#getTask() を使ってタスクに変換する、 すなわち以下のようになります:

        for (Iterator i = tasks.iterator(); i.hasNext();) {
           Task t = (Task) i.next();
           if (t instanceof UnknownElement) {
              ((UnknownElement) t).maybeConfigure();
              t = ((UnknownElement) t).getTask();
              if (t == null) {
                  continue;
              }
           }
           // .... オリジナルのカスタムタスク実装
        }
        

この方法は、ant1.5とant1.6で動作します。

The program I run via <java> throws an exception but I can't seem to get the full stack trace. ? − <java>経由で実行したプログラムが例外を吐いても、 スタックトレース全部を取得できません。どうすればいいですか?

This is a know bug that has been fixed after the release of Ant 1.6.1.

As a workaround, run your <java> task with fork="true" and Ant will display the full trace.

バグです。Ant1.6.1以降のリリースで修正されています。

回避方法として、<java>タスクを fork="true" とすることで、 トレース全部を出力するようになります。