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.
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.
jdk version? IDE version?
See FAQ, and issue #38946; also issue #15430. *** This issue has been marked as a duplicate of 38946 ***
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 NetBeans. I'm using NetBeansIDE-dev-200403011900.
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 directory).
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.
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.
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/
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: -J-Dorg.apache.tools.ant.module=0 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.
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 expanded.
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.
*** Issue 40930 has been marked as a duplicate of this issue. ***
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.
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.
Will just remove structural editing entirely for D.
*** Issue 43232 has been marked as a duplicate of this issue. ***
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.
Created attachment 17451 [details] Diags from 40714-diag.jar
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.
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.
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).
Can't find any xerces.jar in Jalopy/NB 0.3.1, FWIW.
Dug a little more. org.apache.tools.ant.module.xml.AntProjectSupport 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.
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.
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.
*** Issue 47251 has been marked as a duplicate of this issue. ***
closed