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 40714 - Build file corrupted
Summary: Build file corrupted
Alias: None
Product: projects
Classification: Unclassified
Component: Ant (show other bugs)
Version: 3.x
Hardware: PC Windows XP
: P1 blocker (vote)
Assignee: Jesse Glick
: 40930 43232 47251 (view as bug list)
Depends on: 42859
  Show dependency tree
Reported: 2004-03-03 08:42 UTC by gugrim
Modified: 2005-07-15 07:53 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Diagnostic patch JAR for dev builds or 3.6 beta: put in ${netbeans.home}/modules/patches/org-apache-tools-ant-module/ (21.57 KB, application/octet-stream)
2004-03-04 16:17 UTC, Jesse Glick
Diags from 40714-diag.jar (20.51 KB, text/plain)
2004-09-08 02:31 UTC, jpulley

Note You need to log in before you can comment on or make changes to this bug.
Description gugrim 2004-03-03 08:42:04 UTC
When editing a build file I saw that my attributes
had been reordered, as happens when you edit a
property in the tree instead of editing the source
directly. Then I saw that it was much worse than
that; All my entity references has been resolved
inline! It behaved as if that some internal DOM
representation of the build file has suddenly been
expanded into my source file. I don't know what
caused it.
Comment 1 _ ttran 2004-03-03 11:45:59 UTC
jdk version?  IDE version?
Comment 2 Jesse Glick 2004-03-03 16:51:24 UTC
See FAQ, and issue #38946; also issue #15430.

*** This issue has been marked as a duplicate of 38946 ***
Comment 3 gugrim 2004-03-04 09:08:17 UTC
I don't think it is simply a duplicate of that bug. I've known about
that problem since I started using the ant module and I am very
careful never to edit properties in the tree representation. The new
"feature" is that the old propagation of tree to source can now happen
without touching the tree. It has happend several times today, after I
have made some changes. After a short pause the file is updated, i e
corrupted. It seems that only structural changes triggers this, such
as adding or removing entire elements. What this amount to is that
unless the problem is resolved, I simply can't edit build files within

I'm using NetBeansIDE-dev-200403011900.
Comment 4 Jesse Glick 2004-03-04 14:41:54 UTC
You mean that you are only making changes via the textual source
editor, not touching the property sheet nor the Explorer tree of the
build script? In such a case there should be nothing that would
attempt to reformat your build script; I have never seen nor heard of
such a thing happening. If you are sure this is what is happening to
you, please reopen with *precise* details to reproduce the problem
from scratch (preferably using a clean NB installation in a new user
Comment 5 gugrim 2004-03-04 15:05:41 UTC
I mean exactly that, i e I am only making changes via the textual
source editor, not touching the property sheet nor the Explorer tree
of the
build script. Since it doesn't happen everytime it is hard to
reproduce. Once it has started though, it happens again and again
until I restart NetBeans. Can't give you any more details at this time
so I guess I can't reopen the issue, but I'll go back to editing the
files with NetBeans, and make frequent backups, in the hope that some
predictability emerges, in which case I'll then reopen it.
Comment 6 Jesse Glick 2004-03-04 16:11:49 UTC
If true, this would be a serious bug. As I say, I have never heard of
such a thing happening however. Any background information would be
helpful, e.g. a list of any extra modules you have downloaded, or
unusual aspects of your IDE setup or project that you think might be
relevant - even if you cannot reliably reproduce, it is possible that
some hint would let me guess what is wrong in the code and make a fix
that I guess corrects it.
Comment 7 Jesse Glick 2004-03-04 16:17:06 UTC
Created attachment 13830 [details]
Diagnostic patch JAR for dev builds or 3.6 beta: put in ${netbeans.home}/modules/patches/org-apache-tools-ant-module/
Comment 8 Jesse Glick 2004-03-04 16:20:12 UTC
Please try the attached diagnostic patch. It needs to be saved with a
name ending in '.jar' and placed in the
patches\org-apache-tools-ant-module\ subdirectory of the directory
where ant.jar (the NB module) lives, which should be the modules\
subdirectory of the NB installation. If the patch is saved correctly,
you should see a one-line message on the console (or ide.log) during
startup saying that it is in use.

Also add to your bin\ide.cfg:

which will produce quite a bit of diagnostic logging for the module
and send it to the ide.log logfile.

If you see the problem again with these diagnostics enabled, please
attach your log file to this issue and I will take a look at it.
Comment 9 Marek Grummich 2004-03-04 16:48:45 UTC
I havn't succeed to reproduce this issue yet, but I've encountered
this behaviour that is different between a build file and a java file.
I have a build file open in the Editor and a corresponding node
(subnodes - targets) is expanding in the Explorer. When I change
something in some target (e.g name property, add a new task) then the
corresponding node is collapsed in the Explorer. If I perform a
similar activity (add new Field) for a java file, a node remains still
Comment 10 Jesse Glick 2004-03-04 17:57:15 UTC
Marek see issue #20632, quite unrelated.

BTW I just integrated Ant 1.6.1 to the trunk (hope to get it into
release36 as well), and the release notes claim better support for JDK
1.5, so anyone who knows what this bug is about please check whether
1.6.1 solves it.
Comment 11 Jesse Glick 2004-03-11 18:32:11 UTC
*** Issue 40930 has been marked as a duplicate of this issue. ***
Comment 12 gugrim 2004-04-27 18:27:41 UTC
Today it happened again, with 3.6 build 200404071636 and Ant 1.6.1. I
had  expanded the build file in the project tree to execute some
target that had no description. Then I made some changes to the
source. I only used the source editor, not any property editor for
tree nodes. At some point the source was suddenly rewritten.

I did not have the 40714-diag patch installed since I wasn't sure it
was relevant and usable with the released 3.6. Is it? Should I install it?

One possible workaround/solution, that would work for me, would be an
option to completely turn off the ability to edit the Ant file in the
tree and at the same time disable whatever code there is that writes
the build file from the tree.

Comment 13 Jesse Glick 2004-04-27 22:48:02 UTC
Yes, the diagnostic patch should still be applicable I think.

Re. disabling write mode for the structure view: I will definitely
consider this for 4.0.
Comment 14 Jesse Glick 2004-05-05 16:12:04 UTC
Will just remove structural editing entirely for D.
Comment 15 Jesse Glick 2004-05-13 19:04:40 UTC
*** Issue 43232 has been marked as a duplicate of this issue. ***
Comment 16 Jesse Glick 2004-05-13 19:14:24 UTC
Just confirmed that the attached diagnostic patch does do what it's
supposed to in the 3.6 release, at least on Linux / JDK 1.5. I played
with various stuff and it does print a stack trace to
$userdir/system/ide.log as intended when you explicitly make some
structural change e.g. via the property sheet. Did not manage to get
the stack trace to occur via the text editor, so if anyone does,
please attach your log file here. If it can be reproduced it will be
considered as a candidate for a hotfix update to 3.6 due to its severity.
Comment 17 jpulley 2004-09-08 02:31:42 UTC
Created attachment 17451 [details]
Diags from 40714-diag.jar
Comment 18 jpulley 2004-09-08 02:36:57 UTC
This issue is repeatable on my system (NetBeans 3.6, Build
200404071636, Java 1.4.2_05, Gentoo Linux 2.6.8-r3).  I've attached
the log output from the diag jar.

Tell me if there's anything I can do to help get this fixed, it's
driving me to Eclipse.
Comment 19 jpulley 2004-09-08 02:48:15 UTC
I was too brief; here's a repeatable way to reproduce the problem (at
least on my system).  Start NB fresh, open a buildfile in both
Filesystems and the source editor.  Execute a target via the
Filesystems node.  Insert or remove a newline between the attributes
of any (?) element (I used a <target ...>).  (I've observed other
edits, like adding an element, to cause the problem as well.)  Move
the caret around or start typing.  Bang!  The file is reformatted and
the caret repositioned as I type.

One point to emphasize - it's not necessary to actually modify the
file via its node, it's enough to execute a target.  (I'm not sure
whether simply opening the buildfile node is enough.)

Note also that my NetBeans installation isn't "clean".  Let me know if
you need a list of installed modules.
Comment 20 Jesse Glick 2004-09-08 03:22:55 UTC
Can't reproduce using your instructions, sorry. If I could reproduce,
I could probably track it down and perhaps offer some kind of workaround.

Re. your NB not being "clean": I know, I saw your log file. See if you
can reproduce using a fresh installation and fresh user directory. In
particular your copy of the Jalopy module makes me suspicious - maybe
it bundles its own copy of Xerces?

From the stack traces, looks like a Xerces issue. Specifically, a
read-only getter method (getNodeName) calls a synch method, which
temporarily disables mutation events in the document, which is what
you want. Then some code gets run inside this block, and a document
method is called which is supposed to do nothing with mutation events
off - except it does something. So it seems something is setting
mutation events back on in the middle of that block. What, I don't
know; the only thing I can think of is that Xerces turns on mutation
events whenever you add an event listener (whether it is in the middle
of such a block or not); perhaps something is adding a listener in the
middle of the block, for what reason I can't guess. (Could perhaps be
another thread, but that would imply the bug would happen quite
randomly and probably rarely, which does not seem consistent with
jply's observations.)

Note again that this whole class of bugs is impossible in NB 4.0 since
there is no structure writing any more. Only applies to 3.6 (and
perhaps earlier).
Comment 21 Jesse Glick 2004-09-08 03:25:35 UTC
Can't find any xerces.jar in Jalopy/NB 0.3.1, FWIW.
Comment 22 jpulley 2004-09-08 03:42:23 UTC
Dug a little more.
in CVS (1.30) doesn't contain the methods run(...) and regenerate(...)
that are shown in the log file.  I had to search back to 1.23 to find
them, so I'm going to try to upgrade my Ant module.

Uh, how do I do that?  The Update Center doesn't show it, even though
I've got an older one installed. 
Comment 23 Jesse Glick 2004-09-08 04:01:28 UTC
As I said, the problem cannot exist in NB 4.0, which is presumably
what you are looking at in sources. There is no Ant module upgrade for
3.6 which has the structure editing feature removed.
Comment 24 jpulley 2004-09-09 20:13:11 UTC
Ok, it took some work but I did say I'd help.  I installed NB 3.6 as a
different user.  Actually, I installed it several times, trying
different Update Center and 3rd party modules (Ant docs, Ant code
completion, Jalopy, and PMD) one at a time.  (I deleted the install
and user dirs before each installation.)

Finally broke it.  This time I did not install any extra modules; I
did not run the Update Center at all.  I did, however, make some of my
usual options changes (hadn't done that in previous tests):
1) XML Editor --> Tab size --> 4
2) Java Editor -->
    a) Auto popup completion window --> off
    b) Tab size --> 4
    c) Code completion instant substitution --> off
    d) Pair character completion --> off
    e) Update code completion database --> never

I then mounted a local CVS filesystem, opened a build file, went to
work pretty much as described before, and got my failure-cum-success.

Interestingly (to me, at least) I had not modified some of the options
I was most suspicious of.  All the options under Java Sources were
untouched, as were the XML --> General Settings.

FWIW, from the sort of attribute and element edits req'd to break
things, this feels like a timing issue, know what I mean?  Sometimes
it breaks quickly, other times it takes repeated edits in multiple spots.
Comment 25 Jesse Glick 2004-10-22 20:44:18 UTC
*** Issue 47251 has been marked as a duplicate of this issue. ***
Comment 26 Marian Mirilovic 2005-07-15 07:53:31 UTC