Yes I can reproduce this, it is broken. But I do not think it is
straightforward to fix this and I am unwilling to do it just for the
Ant module without help from more general XML support. Currently since
Ant scripts are treated as plain text by the editor, they are read by
NetBeans for purposes of the Source Editor in the platform default
encoding. The result is used inside NetBeans for the Explorer GUI
etc., which thus ignores the XML declaration. Fixing that would
require sniffing the XML declaration, which is not trivial and should
be done by a more general-purpose XML editor support, I think. When
the document is written because of changes in the Explorer, the Ant
module also has no knowledge of what the original XML encoding
declaration was since the parser does not make this information
available, so it defaults to writing out UTF-8. Again fixing that
would require knowing the original encoding which is not trivial. The
Ant module could default to writing out an encoding declaration
matching the platform default encoding, but that would require a
convertor from Java encoding names to XML encoding names.

Workaround: do not make any changes to your build script using the
Explorer. (It is not always recommended anyway: attributes of elements
get reordered on you, etc., due to lack of general XML support.) You
can edit whatever you like as text, so long as you are using the
platform default encoding.

Note that execution of the resulting script is unaffected; Ant does
the parsing before execution straight from the file, not the NetBeans
editor, so it correctly picks up your XML encoding declaration.

Of course if your platform default encoding is set to UTF-8 you should
have no problems if you keep UTF-8 as the declared encoding in all
files, but as far as I know nobody's platform default encoding is set
to UTF-8, unfortunately.

Two remarks:

1) The effect appears also if no editing (in the Explorer or Editor)
has been done. It is enough to execute several times  a target.
2) If one uses also a CVS-filesystem it is tedious that build.xml is
marked as "locally changed" even it has not really (ie. intentional)
changed.

My workaround is to set the OS-filesystem attributs of the build.xml
file to nonwritable and edit it outside of NetBeans if that is needed.

*** Issue 14842 has been marked as a duplicate of this issue. ***

It seems that your "executing a target several times in a row" means
double-clicking rapidly; it can happen that the Explorer interprets a
click as a request to rename the target. Even if you don't actively
rename it, if the in-place rename field appears with a cursor and you
do not exit it with the Escape button, the Explorer sends a rename
event to the Ant module. In NB 3.2.1 this would cause the script to
become modified, even if the target name was not really changed; for
3.3 I have put in a safeguard to make sure this does not happen. Also
you would have had to save changes to the script for it to be really
modified on disk, as changes made in the Explorer change only the
in-memory copy of the script. Anyway, so I am marking this as the
original WONTFIX, since the sub-bug you last reported has been fixed.
(It is somewhat better to file separate bugs for separate problems as
this makes things easier to keep track of.)

committed     Up-To-Date  1.10       
ant/src/org/apache/tools/ant/module/nodes/ElementNode.java

Resolved for 3.3.x or earlier, no new info since then -> closing.

Resolved for 3.3.x or earlier, no new info since then -> closing.