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.
At some point, maybe in 6.5 dev or maybe in 6.1, the IDE began to not correctly compute the classpath for files from nonopen projects. This is very annoying as I often open a series of class files and want to make some minor edits to them before closing. In 6.0 this worked fine. In current dev builds it does not; the files are covered in error badges. If I open the containing project, the badges go away.
I have java.editor open, java.source closed. When I open RepositoryUpdater, I see not badge. Neither do I for a few other files. So I guess more info will be needed (ideally steps to reproduce :-) ), e.g. what project types show this behavior (all?)? Is the classpath (as reported in the Properties window) correct for these files?
Only seems to happen in certain cases - maybe things that did not yet have a parser DB? E.g. I open cnd.dwarfdump/src/org/netbeans/modules/cnd/dwarfdump/trace/TraceDwarf.java from File > Open and it is covered with errors, e.g. import org.netbeans.modules.cnd.dwarfdump.CompilationUnit; ^^^^^^^^^^^^^^^ cannot find symbol In Properties, Compile Classpath is empty (which is correct acc. to project.xml), Runtime Classpath shows the build/classes dir as expected, Boot Classpath shows JDK 5 as expected (i.e. nbjdk.home). If I open the project, the errors disappear. Looks like the problem is that the parser does not find classes in the same source root? Another example: I was recently working on WebLogicalViewProvider.java in a clone of main (under MQ). If I open that file without a containing project, it looks fine. But if I open the same file from a clone of core-main I get the error badges - only on classes from web.project (classes from other modules are fine).
Yes, the caches are never created for the corresponding source root (noone ever registers the ClassPath into GlobalPathRegistry). The support for "foreign" ClassPath (i.e. ClassPath not reachable through GlobalPathRegistry) was always fragile and best-effort only.
Supporting ClassPath's not in GPR was a design requirement from the beginning of NB 4.0 and IIRC it has always worked fine before.
Tome, could you please look at it?
I've tried to play with this. I have a prototype of fix but it has still some problems which are hard to solve. 1) The event from EditorRegs comes late and editor is not refreshed (you need to leave and enter the editor to let the IDE to remove the error badges after scan) 2) The scan is also started by touching the java file inside unopened project by favorites window.
Fixed in jet-main: cd88edd941d4 When the source from unopened project is opened, the project is scanned. When the scan ends the file in editor is refreshed to clean possible errors. The scan of project is triggered by opening a file to prevent scans by crossing the file in favorites.
Integrated into 'main-golden', will be available in build *200908131401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/cd88edd941d4 User: Tomas Zezula <tzezula@netbeans.org> Log: #136522:Compiler error badges on files from unopened projects
One more change (refresh fired only for projects). e733b5def523
Integrated into 'main-golden', will be available in build *200908150201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/e733b5def523 User: Tomas Zezula <tzezula@netbeans.org> Log: #136522:Compiler error badges on files from unopened projects
Seems to be working from what I can tell so far. Should be very helpful especially when updating all occurrences of some pattern across the code base, e.g. replacing a deprecated API: prior to this fix, I could --open all the usages, but then needed to also open every containing project. It was easy to forget to open one of these projects, and the IDE would also open files I left open from the last time I had that project open, usually quite unrelated.