Community
Participate
Working Groups
I'm looking at the method ServiceLocator#registerService and I invoke the call hierarchy. I see no hits for this method, which is called in many places. Search Scope is set to "Workspace". If I invoke search references, I see the references, but they are only "potential" matches. Why are they just potential and not exact hits? Has this behavior changed in 3.2?
Another scenario: ILog#log(IStatus) results in 0 matches found using call hierarchy. Or 600 using search view.
This behaves correctly in my workspace (search and call hierarchy find the same 27 refences). Make sure that the search scope of the call hierarchy view (see drop down menu of this view) is set to Workspace. Please reopen with details steps to reproduce.
I have a very standard installation of Eclipse 3.2.0 because I just lost my entire hard drive. This bug occurred on my previous setup too. So, Call Hierarchy has all default settings, which include "Workspace" scope. I have several internal projects loaded from an internal CVS server. These projects depend only on some parts of Constellation.
I reproduced in a workspace containing some closed projects, and only the GEF Logic example imported as a SRC project. I opened ILog, and searched for the log() method. No hits were found. I was using the 3.2.0 Release build. EMF, GEF, and GMF are in my IDE, maybe a few other features. But only GEF 3.2.0 SDK + Examples should be needed to reproduce the test. http://www.eclipes.org/gef click on downloads page to get the SDK and Examples ZIP.
Exact steps to reproduce: 1. Install Eclipse 3.2.x 2. Download GEF 3.2 and examples (http://www.eclipse.org/downloads/download.php?file=/tools/gef/downloads/drops/R-3.2-200606270816/GEF-ALL-3.2.zip) 3. Unzip in Eclipse install (or add a links/gef.link file that points to GEF) 4. Start a new workspace 5. File>Import>Plug-in Development>Plug-ins and Fragments>Next>Projects with source folders>Next>org.eclipse.gef.examples.logic>Add>Finish 6. Open type ILog 7. In Outline, select log(IStatus) 8. <context menu> > Call hierarchy Observe: the Call hierarchy view doesn't show any children of ILog#log(IStatus)
I cannot reproduce the problem even with latest steps provided by Jerome :-( However, reading again all bug hitsory, I found an interesting point in comment 1: > results in 0 matches found using call hierarchy. > Or 600 using search view. I think this means that problem comes from Call Hierarchy View and not from Search Engine => move to JDT/UI for further investigations.
> I think this means that problem comes from Call Hierarchy View and not from > Search Engine => move to JDT/UI for further investigations. I don't think that is true. All 600 matches are labeled "potential" matches, which is why they are filtered from the hierarchy search. My best guess is that this bug is related to the "PDE classpath" problem.
It has to be said that when you're using the PDE 'add to search' feature, these archives can't correctly be resolved as they are not in the context on a classpath and are therefore only reported as potential matches. So maybe the call hierarchy only adds non-potential matches (I didn't verify) and we should add this option.
(In reply to comment #8) > It has to be said that when you're using the PDE 'add to search' feature, these > archives can't correctly be resolved as they are not in the context on a > classpath and are therefore only reported as potential matches. > So maybe the call hierarchy only adds non-potential matches (I didn't verify) > and we should add this option. I didn't completely understand that, but the bigger issue is that they are potential matches, not whether I can add potential matches to the call hierarchy search. Why are they potential matches? This seems to be because of the way the PDE add all dependent JARs within projects in the workspace. This approach seems flawed. Maybe because there is no implied dependency between two JARs in the same project? For example, if I import "org.eclipse.core.resources" into my workspace, all of a sudden the behavior of the same search returns completely different results (it finds tons of exact matches). The behavior should be the same whether I have a dependency loaded in my workspace or not.
OK, I can reproduce it now. My first try was in a self-hosted workspace and it works in this configuration but not using a standard runtime session... Back to JDT/Core as this is clearly Search Engine issue: it does return all matches as potential ones although some of them should be exact.
Probably caused by bug 73957.
*** This bug has been marked as a duplicate of bug 73957 ***
