This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Build 98, JRE, Standard Edition (build Blackdown-1.3.1-FCS) I'm using german umlauts in my xml-comments of the build.xml. For that the xml declaration includes a encoding="iso-8859-1". After several editing actions and ant-target executions it appears that the build file is reformated and the encoding has changed from iso-8859-1 to UTF-8 and the ant execution fails because of "invalid xml-characters in comments". This behaviour is not predictable but will eventually happen. I found it also in a plain (without any additional modules) and fresh installed NetBeans.
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.