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.
Create/Update the parser database for one project. The .jcb and .jcs files are created in <userdir>/system/ParserDB. Switch to a different project -> the files are gone. When the files are copied to a different location before switching the project and then copied into the ParserDB directory afterwards, they won't be deleted even if the project is switched again. 3.5 Dev build 200303102350 JDK 1.4.1_02 Windows 2000 SP2
The same happens if user creates new project too.
Lowering prio to P2. It's indeed data loss, but not permanent, since parserDB is recreated as background task after mounting new filesystem (= opening/creating project). Reassigning to editor, the bug is actually in editor code, but Vita agreed to fix.
Fixed in main trunk. The parser DB is stored in projects layer. It is not synchronized with Repository during the projects switch. Also it is neccessary to filter out parser DB files when importing userdir from older version of IDE, because these files were stored in session and couldn't be stored in the project now. I've added this filter to Import Settings Wizard. Hopefully this isn't big deal. Let's wait some time and test it before merging this fix to release35. Thomas could you please test it on your side as well? Thanks.
Created attachment 9412 [details] cvs log of changes
Some problems occured after switching projects while the parsing process was running. The parsing should be interrupted before switching to another project. /cvs/editor/src/org/netbeans/modules/editor/java/JCStorage.java,v <-- JCStorage.java new revision: 1.47; previous revision: 1.46
The same for foreground parsing... Interrupt foreground parsing process during projects switching /cvs/editor/src/org/netbeans/modules/editor/java/JCStorage.java,v <-- JCStorage.java new revision: 1.48; previous revision: 1.47 /cvs/editor/src/org/netbeans/modules/editor/java/JCUpdater.java,v <-- JCUpdater.java new revision: 1.57; previous revision: 1.56
Recreating parser DB files after settings imports /cvs/editor/src/org/netbeans/modules/editor/java/JCStorage.java,v <-- JCStorage.java new revision: 1.49; previous revision: 1.48
Corrected filter for filtering parser databases when importing user directory from older versions. /cvs/core/ide/src/org/netbeans/core/upgrade/userdir.cfg new revision: 1.7; previous revision: 1.6 Martine, your last patch seems to work good. Milane, could you please test this once more, if there will not be any problems I will merge it in release35 branch tommorow.
"Project part" verified. Can be merged to release35.
merged to release35
The fix causes big startup time regression as it fully initializes (parses) JCStorage during the startup. Please improve the fix to not have this side effect.
fixed in [maintrunk] diffs: http://editor.netbeans.org/source/browse/editor/src/org/netbeans/modules/editor/EditorModule.java.diff?r1=1.98&r2=1.99 http://editor.netbeans.org/source/browse/editor/src/org/netbeans/modules/editor/EditorWarmUpTask.java.diff?r1=1.4&r2=1.5 http://editor.netbeans.org/source/browse/editor/src/org/netbeans/modules/editor/java/JCStorage.java.diff?r1=1.52&r2=1.53 Petr, could you please verify it? Vita, could you please review the fix? Thanks.
Martine, the fix seems correct to me.
Created attachment 9646 [details] Patch for release35.
Eman could you please verify the patch? Copy the attached editor.jar to <NB-install>/modules/patches/org-netbeans-modules-editor folder. Thanks.
Verified in NB 3.5 build 200304012350.
approved for 3.5
integrated into [release35] /cvs/editor/src/org/netbeans/modules/editor/EditorModule.java,v <-- EditorModule.java new revision: 1.97.2.2; previous revision: 1.97.2.1 /cvs/editor/src/org/netbeans/modules/editor/EditorWarmUpTask.java,v <-- EditorWarmUpTask.java new revision: 1.4.2.1; previous revision: 1.4 /cvs/editor/src/org/netbeans/modules/editor/java/JCStorage.java,v <-- JCStorage.java new revision: 1.45.2.3; previous revision: 1.45.2.2
Verified in build 200306022350 release35.
Please refer to issue 32042 where I described a testcase. It's not fixed. When I switch projects, then the parser DB files are deleted. I can re-build them ok. When I switch again, then they are lost again. I realise that the parser DB files are now in project directories. System Info: Product Version = NetBeans IDE Dev (Build 200310221740) Operating System = Windows 98 version 4.10 running on x86 Java; VM; Vendor = 1.4.1; Java HotSpot(TM) Client VM 1.4.1-b21; Sun Microsystems Inc.
It seems to work fine on my machine. Parser DBs are preserved during projects switch (also the issue #32042 was closed as worksforme).
Verified in release 35 and dev build 200311191900. I tried reproduce the scenario described in original message on last dev and r35 builds. Result of my test is that the Parser DB is not removed when switching projects.
I would agree that this has morphed from the original issue into something else that is more difficult to reproduce. However, description and symptoms are exactly the same. I find it hard to reproduce myself because at present I am not switching projects that often. One additional observation could probably explain why this happens: When I opened an alternate project today after a long time, one file system was mounted in explorer as "Duplicate " + <original file system name> although it was NOT duplicate except the last directory name in the path. Files in the editor also had the "Duplicate " prefixes in the tabs. Without making any changes, I re-opened the project and the "Duplicate" file system was mounted normally. However, the code completion did not work any more.
I cannot reproduce it. Which build do you use?
I find this difficult to reproduce myself. It happened with q-build 2003-10-31-2030.
Because the problem is not reproducible always as it was in this issue I have created another issue (issue #37481) with lower priority to track the problem you described.
Verified - The original issue was fixed and the scenario from B.T. is described in issue #37481.