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.
As reported on several occasions in other issues mentioning problems with indexing/scanning running a j2se project is blocked by indexing due to the need for resolving the project's main class, which in turn needs access to the index.
"Resolve" the main class how? The main class is defined in the project's run config. AFAIK all you are doing is verifying that the class exists so you can show a dialog rather than print a NCDFE if it does not, which is nice but far lower priority than the major performance issue.
I can't understand why this is only P3 (and why it's postponed to 6.8) For me having to wait for 30-45 seconds when hitting "run" is nearly a blocker.
Is it possible to fix this in prior a port the fix into 6.7patch1 if it isn't too dangerous? thanks
I don't have the fix yet, so I don't know.
I have a fix allowing run|debug the project|file in the time of background scan. But there is a problem with compile on save, when the compile on save is turned on I have to wait on the background scan as before. The class files used in compile on save are produced and affected by background scan.
Also there is a problem with debugger. The project part works fine, the debugger stops on the break point but step next causes access to java model which stops the debugger.
Fixed with limitations described above. 1) The project cannot be started during bg scan when the compile on save is active (explained above). 2) The debugger cannot be started during bg scan as the debugger blocks the AWT. I will try to find some solution with Martin E. http://hg.netbeans.org/jet-main/rev/3655e3539716 http://hg.netbeans.org/jet-main/rev/833e1b8c611f
#1 is to be expected, I think.
I think it makes sense for the debugger to wait, since the user is most likely, really interested in any changes when "compile on save" is selected. But, I also wonder, if more feedback to the user, on these "waiting moments" would not be appropriate. If the background "indexing" could have some progress feedback to the user that would make it more probable that the user could get some comfort that the IDE is doing something that is "good" for them. But, the most important thing, is that if I am compiling a depended on project, the dependee project compilation and indexing should not impact my work. There really needs to be a way to say "I'm only interested in results for Project-X" so that any "wait" operation is conditionalized on that associated work. I could imagine locks with project granularity being created and held/used by the indexing so that if I say "run X" and project X has dependent indexing/compiling happening, that two things happen. One, any such pending work is moved into the front of the queue, as possible. And two, when all work I am dependent on is completed, my run can start while the other work is going on in the background.
Integrated into 'main-golden', will be available in build *200907080200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/3655e3539716 User: Tomas Zezula <tzezula@netbeans.org> Log: #166527:Running project blocked by indexing
v.
Be carefull when applying the patch for this into release67 - you *must* include also patch for 168294!
The fix has been ported into the release67_fixes repository. http://hg.netbeans.org/release67_fixes/rev/d202b9af980e
v in 6.7.1
*** Issue 167724 has been marked as a duplicate of this issue. ***