Community
Participate
Working Groups
DM (11/28/00 11:09:12 AM) 0. Start Eclipse (no workspace) 1. Create solution and Java project with JUnit 2. Open search view to prevent exception (known bug when working in IDE) 3. Open junit.tests.AllTests (from JUnit) and select suite() in the Outline. 4. Choose "Declarations" in the context menu (IMPORTANT: Use "Declarations in Hierarchy" if available) ==> no search result The declaration search uses com.ibm.jdt.core.search.HierarchyScope. It works when the search is performed via context menu in the type hierarchy. BUT: When using a binary type (e.g. java.awt.CardLayout) the search does also not work when performed via hierarchy view. SOURCE CASE: In both cases the type to create a new HierarchyScope is com.ibm.jdt.core.SourceType (id=1869). I guess the problem its parent: in case of the Outline it is com.ibm.jdt.core.WorkingCopy (id=1873) BINARY CASE: the type is com.ibm.jdt.core.BinaryType with com.ibm.jdt.core.ClassFile as parent PM (11/28/00 1:30:02 PM) Might be related to the fact our JavaElement declaration queries are too accurate (only find the matches on the same declaring type, i.e. the one you already have). JBL (11/29/00 4:50:17 PM) Actually the problem is that we fail when finding out that the type hierarchy scope encloses the indexed file. JBL (11/30/00 6:13:34 PM) Fixed the binary case. The source case still doesn't work because the hierarchy scope is created on a working copy. Need to investigate more. JBL (12/4/00 3:29:53 PM) Jabiru 28 doesn't use hierarchy scope when searching from the context menu any longer. Is it ok to close? DM (12/5/00 8:37:38 AM) No. Why do you think that it doesn't use hierarchy scope? If it doesn't then its my bug. In our (ZRH) version of Jabiru 28 are 2 context menus (in the Outline and in the Type Hierarchy view): Declarations (should use workbench scope) Declarations in Hierarchy (should use type hierarchy scope) JBL (12/5/00 10:45:43 AM) I'm saying it doesn't use the hierarchy scope because when I put a breakpoint in SearchEngine.search(IWorkbench, IJavaElement, int, IJavaSearchScope, IJavaSearchResult) and I use Declarations in Hierarchy, then the scope is a JavaWorkbenchScope not a HierarchyScope. JBL (12/5/00 10:48:14 AM) If you decide to put the hierarchy scope back, you should not pass an IType from a working copy but the IType from the compilation unit as the TypeHierarchyViewPart does. i.e. ICompilationUnit cu= type.getCompilationUnit(); if (cu != null && cu.isWorkingCopy()) { type= (IType)cu.getOriginal(type); } JBL (12/5/00 11:06:48 AM) Also note that if you pass an IJavaElement to the search engine in the case of Declarations (in workbench) you will get the exact same results as in the case of Declarations in Hierarchy. If the semantic you want in the first case is "all declarations with the same name", then you should use search(IWorkbench, String, int, int, IJavaSearchScope, IJavaSearchResultCollector) DM (12/5/00 5:31:48 PM) I agree that the type is not handled correctly by the UI - filed a PR. However, this PR is about a method and not a type. What you say (i.e. the JavaElement API being called for search) is related to types and not to the method search. In the method search I use the string pattern API to search. If you put a breakpoint in the "stringPattern" API and repeat the test case you will see that I use the following scopes: JavaWorkbenchScope for Declarations HierarchyScope for Declarations in Hierarchy I guess it is not the search that is wrong. I guess the API to construct a HierarchyScope returns a scope which seems not to work. JBL (12/5/00 12:05:26 PM) I'm sorry. I misread this PR. I was able to reproduce the problem and I will look at it. JBL (12/5/00 12:14:46 PM) In fact the problem with method declarations in a hierarchy scope is the same as type declarations in a hiearchy scope: if the hierarchy scope is created on a type in a working copy, then it won't work. I will change the constructor of the hiearchy scope to not allow it to be created on a type in a working copy. DM (12/5/00 6:33:11 PM) Couldn't the creator be smart enough to execute the code you mentioned: ICompilationUnit cu= type.getCompilationUnit(); if (cu != null && cu.isWorkingCopy()) { type= (IType)cu.getOriginal(type); } JBL (12/5/00 3:17:12 PM) I wanted to let the UI do it to give it a chance to tell the user that he was searching from a working copy and the result would be in a compilation unit. For example, if the user creates a compilation unit A.java and he/she modifies its content to be: public class A { void foo() { } } class B extends A { void foo() { } } without saving it. Then if he/she searches for declarations of foo() in the hierarchy, there would be no match. That could be interpreted as a bug. DM (12/6/00 9:32:27 AM) I agree if you/the search engine give me that feeling/API (exception for working copies) but then I also want it when I do a search for a JavaElement that is a working copy - not only if I want to create a hierarchy (i.e. the whole search API has to conform to your new definition). I rather like working copies to be handled by the search engine because even if the input is a working copy I still want to search for the references to it or for all its declarations (no matter if the content in the editor has been changed or not). Furthermore the problem you describe remains because I can search for a text pattern and there I will also not get support by the search engine. Please note that one part of the PR is against a binary element which is read-only: When using a binary type (e.g. java.awt.CardLayout) the search does also not work when performed via hierarchy view. JBL (12/6/00 11:06:58 AM) I agree with you for the working copy case. All I was saying was that for now this doesn't work and it would be good if you could workaround the problem on your side. For the binary case, I just verified that it is fixed. Do you still have the problem with build 0.014a? DM (12/6/00 6:34:58 PM) Binary case verified: OK. No problem, I can put the workaround in the UI code until it is fixed. DM (12/7/00 9:38:10 AM) Added above code to a workaround (Jabiru > 28) in: IBM Java Base UI [28.20 dm] com.ibm.jdt.ui.search [28.20 dm] FindHierarchyDeclarationsAction.java [28.20 dm] JBL (6/18/2001 2:30:50 PM) Need to ensure that a hierarchy scope can be created on a working copy.
PRODUCT VERSION: Eclipse 013+, VAME, JDK 1.2.2
Added support to allow the creation of a hierarchy scope on a type coming from a working copy.