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.

Bug 16102 - ant changes the encoding entry in build.xml from iso-8859-1 to UTF-8
Summary: ant changes the encoding entry in build.xml from iso-8859-1 to UTF-8
Alias: None
Product: projects
Classification: Unclassified
Component: Ant (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Jesse Glick
: 14842 (view as bug list)
Depends on: 20532
  Show dependency tree
Reported: 2001-10-02 09:00 UTC by ladermann
Modified: 2003-06-30 14:47 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description ladermann 2001-10-02 09:00:56 UTC
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.
Comment 1 Jesse Glick 2001-10-03 09:47:02 UTC
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.
Comment 2 ladermann 2001-10-05 12:00:46 UTC
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)

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.
Comment 3 Jesse Glick 2001-10-08 14:46:08 UTC
*** Issue 14842 has been marked as a duplicate of this issue. ***
Comment 4 Jesse Glick 2001-10-22 20:45:07 UTC
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       
Comment 5 Quality Engineering 2003-06-30 14:43:42 UTC
Resolved for 3.3.x or earlier, no new info since then -> closing.

Comment 6 Quality Engineering 2003-06-30 14:47:07 UTC
Resolved for 3.3.x or earlier, no new info since then -> closing.