Summary: | [select] Navigate to classes in workspace even if not on classpath | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Jeff McAffer <jeffmcaffer> | ||||||
Component: | Core | Assignee: | David Audel <david_audel> | ||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||
Severity: | enhancement | ||||||||
Priority: | P3 | CC: | daniel_megert, jerome_lanneluc, markus.kell.r, martinae, mlists | ||||||
Version: | 3.4 | ||||||||
Target Milestone: | 3.5 M3 | ||||||||
Hardware: | PC | ||||||||
OS: | Windows Vista | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Jeff McAffer
2008-05-19 20:21:48 EDT
Even just opening a type from the target does not allow you to navigate. Basically is seems that if the type open is binary it is treated as a complete second class citizen. Half of me is suspecting that this is a long standing issue though it is also hard for me to understand if that is true, what I've been doing in the past that made it all ok. I tried adding everything to Java search and that addressed the issue of navigation. While clearly this is a long standing issue, I thought we had made some progress on it. Is there an option that could be used in this situation? Novice (and not so novice) users are very confused when they can see a type referenced in Java and they cannot navigate to it though they can open type on it and it clearly is there. Code resolve works on the project's classpath. The project classpath is defined for the sources. All the dependencies of your JAR's are normally not on the classpath and you also don't want to put them there. I assume this is the discussion from bug 73957 and the cure would be bug 110176. To reproduce: 1. New workspace 2. Import 'org.eclipse.core.resources' 3. Create a Java project 'P' 4. Add 'org.eclipse.jdt.core_3.4.0_v865.jar' as an external library to 'P' 5. Attach the corresponding source 'org.eclipse.jdt.core.source_3.4.0.v_865.jar' 6. Open 'IJavaElement' 7. Go to 'getResource()' 8. Select 'IResource' 9. Press F3 Observe: 'IResource' in 'org.eclipse.core.resources' is not opened If we fail to resolve a type referenced in a source attachment, we could use the search all type names (as Ctrl+Shift+T does) on the selection. Note I believe this scenario has never worked. Thus marking as enhancement. (In reply to comment #4) Renaming title accordingly David, please look at this for M3 Created attachment 114643 [details]
Proposed fix
With this patch if no types are found in the current project scope then types are searched in the workspace.
SelectionEngine use a searchAllTypeNames() request to find quickly the selected type.
Released for 3.5M3. Tests added ResolveTests2#testBug232880a() -> testBug232880i() Could you make the search case-sensitive? Normal resolution is also case-sensitive. In HEAD, I now get hovers for every second word in a normal Javadoc description. E.g. Javadoc for java.lang.annotation.Retention: - CLASS wrongly matches java.lang.Class - member wrongly matches java.lang.reflect.Member - ... >In HEAD, I now get hovers for every second word in a normal Javadoc
>description.
Agree, this is not good.
Created attachment 114672 [details]
Additional patch
As said in previous comments, my patch is not good because the search must be case-sensitive. With this additional patch the search is case-sensitive.
It also add a regression test
ResolveTests2#testBug3232880j()
The additional fix is released Verified for 3.5M3 using I20081026-2000 |