Given
    <property file="this_sets_all_the_'generated.*'_stuff.properties"/>
    ....
    <property name="objdir" location="${generated.objdir}" relative="true"/>

and a cleanup target including a task like
    <delete includeEmptyDirs="true">
      <fileset dir="${objdir}"/>
      .... lots of other filesets ....
    </delete>

I wanted to demonstrate to a new developer that running the cleanup target when the "generated-stuff" properties file was missing, didn't really do anything but was "safe" in that it wasn't going to run amok on the filesystem, etc.  And everything was fine; we got the diagnostic:

    BUILD FAILED
    C:\example\build.xml:1234: Directory does not exist: C:\example\${generated.objdir}

Yes, the constructed pathname has the un-expanded property name inside it, "C:\example\${generated.objdir}", and that's correct behavior for Ant.  Everything still fine.

I then ran Ant with '-d' to show what <delete> was trying to do behind the scenes, and got:
[delete] Directory does not exist: C:\example\${generated.objdir}
        at org.apache.tools.ant.taskdefs.Delete.handle(Delete.java:777)
        .... stacktrace ....

Again, fine.  We then added quiet="true" attribute back to the <delete> task (I had removed it for demonstration purposes to the new boy).  And that was fine.

However, when running with "-d", the diagnostic looks like this:

[delete] Directory does not exist: C:\example\${generated.objdir}Directory does not exist: C:\example\${generated.objdir}
        at org.apache.tools.ant.taskdefs.Delete.handle(Delete.java:777)
        at org.apache.tools.ant.taskdefs.Delete.execute(Delete.java:681)

The bug is that the diagnostic is printed twice.  And honestly even that would be fine if there were a newline between the two, but as it is, things get difficult to read once "C:\example" is replaced by an actual real-world path.

Using the web interface at git-wip-us, I looked at taskdefs/Delete.java and I still don't know why it's being printed twice.  Presumably the -d flag sets 'failonerror', I guess, but I don't know why that would case the line now at 679 to be invoked twice -- or rather, why it's being called *more than once* and simultaneously *not infinitely* if there's no break/continue out of the filesets loop after the 'handle' call.  Too difficult to figure out over the web, anyhow.  :-)

Anyhow, it's only a minor bit of noise and doesn't break anything.  Cheers!