Community
Participate
Working Groups
Using build I20041111, I did a search for all references to the method ResourcesPlugin.getWorkspace() inside my Team working set which contains the team plugings. The result contained 304 results, many of which were not in the team plugins. Some of the bad matches were marked potential matches while others were not. I would expect a search for the references to a static method to return only real mathces. I would also expect that a search in a working set would only include classes that were contained in the working set.
Michael, two questions: - how is your workspace setup. Do you have all binary projects imported or do you reference the jars in the Eclipse installation via the PDE container. - can you give some details how your working set looks like. Does it contain only projects ?
I have the entire Eclipse code base as source loaded from the repository (I may be missng one or two if they were new since 3.0) and I believe that most, if not all, projects are using PDE classpath containers. My working set is a Java working set which contains only projects (the the org.eclipse.team.* plugins).
The problem comes from the fact that the PDE class path container puts "plug-ins" which aren't loaded into the workspace as external libraries onto the class path. Per definition external libraries are considered to be part of the project and therefore are searched as well. In this case you have to deselect the libraries PDE puts onto the class path in the working set. There is nothing JDT/UI can do here. The only solution to do this automatically is if PDE annotates the library and the JDT/Core ignores it during searching. Moving to JDT/Core to comment on this idea.
This problem also makes the References > Project utility annoying, as I see hits from all my plugin's dependencies instead of just my plugin's own. Perhaps the simplest solution would be for JDT to search only the package fragment roots whose parent is the IJavaProject itself.
then again, sometimes you would want to see what other (external) plugins are referencing a particular method without having to import the whole universe into your workspace. In this case, the current JDT behavior is perfect.
If time permit (really not sure), otherwise defer to next release
Just to clarify: we shouldn't in general ignore external Jars when searching. If users don't do plug-in development searching external jars of a project contained in a working set is the right thing to do.
Unfortunately, defer post 3.1
*** Bug 88744 has been marked as a duplicate of this bug. ***
Reopen for 3.2
*** Bug 131799 has been marked as a duplicate of this bug. ***
Unfortunately, has to defer it again. Set target as 3.3 to take this bug in early 3.3 dvpt...
Reopen
I missed the point when Dirk moved this bug in our land but it sounds to me (now) that JDT/Core already has API ways to exclude this indesirable matches. Constants IJavaSearchScope.APPLICATION_LIBRARIES is typically done for this purpose... If user creates an IJavaSearchScope with this bit unset in includeMask parameter, then it only gets exact matches in his source folders. I've made some try and it works perfectly using 3.2 RC4. So, IMO, problem is only due to the fact that JDT/UI does not let user to set/unset this bit while performing searches, neither in menu actions nor in Java Search Dialog... Move to JDT/UI for comments or put it back if I missed something obvious...
Created attachment 41889 [details] Advanced Java Search Dialog Here's a patch to apply on org.eclipse.jdt.ui project 3.2 RC4 version (eg. v20060512-1326) which allow user to set all values on limitTo, searchFor and includeMask parameters while searching java element or a string pattern using Java Search dialog. It helps to show that IJavaSearchScope.APPLICATION_LIBRARIES bit unset addressed the initial issue.
I'm not sure if this bug has to do with IJavaSearchScope.APPLICATION_LIBRARIES. Either the library is in the working set or it isn't. Michael, are you sure that your working set has no libraries selected? You have to explicitly select only the source folder. A selected project is by definition also containing all the libraries.
My Team working set includes all the Team projects. Are you saying that searches on that will include all the plugins that Team depends on as well? If so, I think what you are also saying is that I would need to create another Working set that contained only the source folders of those plugins if I wanted to restrict the search to those plugins. So I will need two working sets: one for the packages Explorer and one for search. Is this correct? Perhaps the answer is to have a working set filter on the search view that works the same way as the filter in the packages explorer (i.e. show me only the files that are in the current working set).
> Per definition external libraries are considered to be part of the project and > therefore are searched as well. When doing non-PDE developement, the user might choose to create a project containing just external libraries, and keeping his/her src project, and therefore project working set, free from others' class libraries. The best solution might be to prioritize search results. If a "hit" is found in a source file, it should have higher priority than all hits found in .class files. Priorities might be grouped in the search view. Maybe assigning an interest level to a given resource has more general use than even just search results. For example, perhaps file open history.
added additional checkboxed to include/exclude search in source, jre, required projects and application libraries > 20060807
verified in I20060810-0010
