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.
When you mount a folder in Favorites that contains NB project directories and do a full-text search of them, the IDE rescans the project classpaths for changes, even though I didn't have the projects that were being searched open in the IDE.
This is not caused by the search. You can reproduce the same behaviour (i.e. scanning of classpath roots) simply by manual expanding nodes for project directories, their subnodes and their subnodes. I do not know which module is responsible for it and whether it is a "feature" or a "bug". Reassigning to projects for further evaluation.
As designed. Working with a project means it gets loaded, whether it is opened in the Projects tab or not.
Makes perfect sense from the implementation point of view. From the user's point of view, seems like doing a search of a directory in the Favorites window and getting multiple Scanning Project Classpaths dialogs would definitely seem like a bug. Leave it up to you guys to decide.
Folder expansion probably triggers project loading by checking for action enablement. If projects are loaded during full-text search, it may be a bug in the utilities module, but I don't know.
BTW - there have been some complaints about this on netbeans feedback. For users with large projects open this is not trivial.
I will try to investigate to find out who is calling ProjectManager.findProject and reassign as appropriate (or close if the call is simply unavoidable).
I did some investigation, using --- java/api/src/org/netbeans/api/java/classpath/ClassPath.java 1.33 +++ java/api/src/org/netbeans/api/java/classpath/ClassPath.java @@ -432,6 +432,8 @@ * @see ClassPathProvider */ public static ClassPath getClassPath(FileObject f, String id) { + System.err.println("ClassPath.getClassPath: " + f + " " + id); + Thread.dumpStack(); if (f == null) { // What else can we do?? Backwards compatibility only. Thread.dumpStack(); 1. JavaNode.resolveIcons uses JMI to find the package name of *.java files and thus whether it should mark the node with an error icon due to incorrect package name; also it checks for a main method. JMI requires the classpaths to be known. These checks could probably be rewritten to not use JMI, but would be some work and could easily introduce other bugs or performance problems. 2. For *.class, CompiledDataNode also checks classpaths in order to add an icon for some other error condition. 3. For *.jsp (I guess), JspLoader checks classpaths for reasons I don't know. I don't foresee authors of all of these modules rewriting how they display data nodes just for the sake of this bug, but if any of the CC'd modules wish to optimize their handling of search results, go ahead and reopen and assign to yourself.
Oh, and: if you have the Navigator window open and you actually select any *.java search hit, then it will need to scan CP for that file in order to display the Nav window. (Javacore does not have the ability to provide a list of declared methods in a source file without obtaining the CP for that source file, despite the fact that the list of methods cannot logically depend on the CP.)