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.
Working with NB 7.0.1 Dev 201106020000 Occasionally but not rarely, several unit test source files are marked red in the editor because some classes are not found. Even restarting NB or clean-recompiling the whole project does not solve the issue. The only solution is to open the classes that are marked in red, make a dummy modification and save them. After a while the red marks disappear in the unit test code.
Without a test case I cannot say whether this is a bug in the Maven support or the Java parser infrastructure.
Of course, but the problem is there. I will add more details as soon as I can identify the reproducible testcase. Do you have suggestions on what I can do to further diagnose the issue when I encounter it? If you do not give me any assistance, the problem will remain there unsolved.
(In reply to comment #2) > I will add more details as soon as I can identify the reproducible testcase. Well, reopen if and when you come up with this information. > Do you have suggestions on what I can do to further diagnose the issue when I > encounter it? Using the NetBeans Project Metadata Inspector module (on Auto Update / Plugin Portal) you can see whether the classpath for src/test/java includes everything it should. If not, there may be an issue in the Maven support (presumably triggered somehow by your project setup and the content of your local repository). If so, there is probably an issue in the Java parser, though something like bug #192647 could also be to blame. It is tricky to say since the bug appears to be worked around by refreshes. If shutting down the IDE, deleting $userdir/var/cache/index/, restarting the IDE, and waiting for scanning to finish clears the errors, then a bug in the Java parser seems most likely.
A huge number of files in the Windows temp directory might have been the cause.
Hmm. I cannot think of any good reason offhand why that would result in spurious errors in the Java editor. Perhaps some code tried to create a temp file in the course of some computation, was denied, and then "recovered" from the error without logging it properly, but I have no guesses at what that code could have been.