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.
For some time I have noticed that if I try to run a build of a Maven project while scanning is in progress, the Output Window tab opens but the mvn command is not run until scanning finishes. I tracked the pause down to CosChecker.cleanGeneratedClassfiles; this is always called when Build Project is run, and blocks in BuildArtifactMapperImpl.clean -> SourceUtils.waitScanFinished. If the project is really being tracked for CoS - e.g. if you have been running single unit tests from it - then it makes sense to wait for the scanning to finish, in case the scan winds up updating some of those classes. But usually CoS is not in active use on the project; so BAMI.clean is waiting for scanning to finish just so it can determine that .netbeans_automatic_build is not there and it need not do anything anyway!
Created attachment 108700 [details] Patch for java.source Attaching a patch which simply makes QUICK_CLEAN return early in the common case. Not sure about the possible effect on other project types; could not find any mention of QUICK_CLEAN in java.j2seproject or java.api.common, though it is used from autoproject.java. (BAMI.clean is called from TranslateClassPath when clean=true. But clean=true only in clean-snippet.xml, which does not seem to be used at all since ProjectRunnerImpl.execute has a special impl for QUICK_CLEAN. Am I missing something? Looks like the fix of bug #152728 left behind dead code.)
Created attachment 108701 [details] Workaround in maven Alternate patch which works around the bug in the Maven support code, by essentially precomputing the conditions under which QUICK_CLEAN might block.
I think the first patch is preferable since it is much simpler, and does not require workarounds in every project type using QUICK_CLEAN; reassigning for evaluation. I am not sure if there is any possible race condition whereby the scan would visit a classes dir which did not have .netbeans_automatic_build before and suddenly add it (and write some generated classes there), after QUICK_CLEAN had already decided the dir was clean. Ideally QUICK_CLEAN would never block, and would somehow ensure that any ongoing scan knew to skip these dirs.
I currently do not see a race condition that could occur, so simply applying the patch: http://hg.netbeans.org/jet-main/rev/c3fe51e7a946 http://hg.netbeans.org/releases/rev/a59e62cbaaf4
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/c3fe51e7a946 User: Jan Lahoda <jlahoda@netbeans.org> Log: #199145: applying Jesse's patch, QUICK_CLEAN should not wait for scanning