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?
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.
#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)
User: Tomas Zezula <email@example.com>
Log: #166527:Running project blocked by indexing
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.
v in 6.7.1
*** Issue 167724 has been marked as a duplicate of this issue. ***