Applies to:
Ant 1.7.0
Description:
Ant 1.7.0 doesn’t build from sources without JUnit
Cause:
When building Ant 1.7.0 from the source release without junit.jar the build fails with the message “We cannot build the test jar unless JUnit is present”.
With Ant 1.7.0 ant-testutil.jar is added as part of the distribution and this causes a hard dependency on JUnit – at least in version 1.7.0.
Applies to:
Ant 1.3, Unix
Description:
Occurs while using Apache Ant.
Cause:
The antRun script in ANT_HOME/bin has DOS instead of Unix line endings.
Applies to:
Ant, Solaris, Linux
Description:
Occurs while using Apache Ant.
Cause:
There is a bug in the Solaris reference implementation of the JDK.
Applies to:
Ant 1.4, Windows XP, JDK 1.4
Description:
Occurs while using Apache Ant.
Cause:
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.
Applies to:
Ant 1.5.2
Description:
Occurs while using Apache Ant.
Cause:
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.
Applies to:
Ant
Description:
Occurs while using Apache Ant.
Cause:
You have run the program via
Applies to:
Ant
Description:
Occurs while using Apache Ant.
Cause:
The XML formatter needs the DOM classes to work. If you are using JDK 1.4 or later they are included with your Java Runtime and this problem won’t occur. If you are running JDK 1.3 or earlier, the DOM classes have to be on your
Applies to:
Ant, JDK 1.5
Description:
Occurs while using Apache Ant.
Cause:
While JDK 1.4.x contains a version of Xalan-J 2, JDK 1.5 have moved to XSLTC. Since this task uses Xalan’s redirect extensions for its internal stylesheet, Ant prior to 1.6.2 didn’t support XSLTC.
Applies to:
Ant, Mac OS X
Description:
Occurs while compiling project under Mac OS X
Cause:
Apple’s Java VMs reside in /System/Library/Frameworks/JavaVM.framework/Versions/X.Y.Z and JAVA_HOME will usually be something like /System/Library/Frameworks/JavaVM.framework/Versions/X.Y.Z/Home.
Inside this home directory there is a symbolic link named shared_bundle that links three levels up, i.e. to /System/Library/Frameworks/JavaVM.framework.
If your build file contains a fileset like
Ant is going to follow the shared_bundle symlink and ends up recursing into all your installed VMs. Even worse, it will enter /System/Library/Frameworks/JavaVM.framework/Versions/X.Y.Z/Home and will once again follow the same symlink.
Ant versions after Ant 1.7.1 will detect the infinite loop they are in, but the resulting fileset may still be too big to deal with, in particular if you have many different VM versions installed. The problem is amplified by the fact that each installed version has a shared_bundle symlink in it.
Applies to:
Maven
Description:
Occurs while using Maven.
Cause:
This means that the parameter being overriden in the pom.xml is read-only.