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.
Product Version: NetBeans IDE Dev (Build 201506290001) Java: 1.8.0_45; Java HotSpot(TM) 64-Bit Server VM 25.45-b02 Runtime: Java(TM) SE Runtime Environment 1.8.0_45-b14 System: Windows 7 version 6.1 running on amd64; UTF-8; en_US (nb) User directory: C:\dev\Netbeans\user\dev Cache directory: C:\dev\Netbeans\cache\dev Sometime in the past week, the "Background scanning" task began blocking the "Run Project" command. Meaning, if you try running a task, the Output Window will get created but nothing will begin executing until the "Background scanning" task completes. (I am using a Maven Java project but I don't think the project type matters) This behavior is problematic because for larger projects, background scanning can take almost one minute.
Increasing priority to P2 because this is a regression and makes the IDE blocks for over 30 seconds at a time for medium-sized projects.
Not sure about maven. In Ant based projects when Compile On Save is disabled the Background Scan does not block project execution. When Compile On Save is enabled the Background Scan needs to block the execution as the classes for Compile On Save are produced by Background Scan (all background scans scheduled before the project execution needs to finish). I don't know how this is implemented in maven, if it's same as in Ant it's wontfix. If execution is blocked even when CoS is disabled it should be fixed.
Tomas, The main purpose of Compile on Save is to speed up the compile-run cycle, but with this recent change the compile-run cycle is actually slower for me than recompiling the entire project every time. And that is saying a lot, because the project takes a long time to compile through Maven... First let's see if this issue is some Maven-specific bug. But if not, I suggest investigating whether the compiler is "touching" more files than necessary, and I would also change the UI to indicate you are recompiling as opposed to simply running a Background Scan. So bottom line: CoS needs to be substantially faster than Maven compile. If that's not the case, we need to investigate why and improve performance. Let's hope this is a simple Maven-specific bug.
Tomas, I just noticed something funny. If I "Clean and Build" the root Maven module, the compiler will run for 1:20 minutes. Netbeans then detects the change and proceeds with "Background scanning" for the next 1:40 minutes. First of all, you're compiling the code twice. Secondly, I am allowed to run sub-modules while the parent is building, but I stop being able to do so the minute "Background scanning" kicks in. If I am able to run in the first case, I expect to be able to run in the same case. This is only one aspect of the overall problem, but one which should be easy to understand and reproduce.
fixed in jet-main #0af1a36a6d9c
Integrated into 'main-silver', will be available in build *201507210001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/0af1a36a6d9c User: Tomas Stupka <tstupka@netbeans.org> Log: Issue #253244 - Background scanning task blocks project execution
>I just noticed something funny. If I "Clean and Build" the root Maven module It was a bug in the Maven which Tomas Stupka recently fixed. Now it behaves in the same way as in Ant projects. Only those actions which need a CoS classes are blocking the project action when compile on save (CoS) is enabled. The build does not need CoS caches so it is not blocked.