Having Problems?
Having Problems?
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.
Ensure that you are actually running the version of Ant that you think you do
Many tools include a version of Ant and some Operating Systems even install it by default now, so you may have a version of Ant installed that you haven't been aware of.
One of the first things to do is to run
          
          ant -version
          
          and
          
          ant -diagnostics
          
          to be sure.  Also, we highly recommend that you run Ant with
          an empty CLASSPATH.  If any other version of Ant can be
          loaded from the CLASSPATH, many types of errors may happen
          because of incompatible classes being loaded.
See the FAQ for some examples, but many other problems are a result of an old version of Ant on your system as well.
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.
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 -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.
           
              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] 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.
            
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. 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.
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.
         
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 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. 
         
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.
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.
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.
         
            If you have a patch to submit and are sending it to the
            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:
            
            diff -u Javac.java.orig Javac.java > javac.diffs
            
            or, if you have source from 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.
        







 
    