Community
Participate
Working Groups
in RC1 - import as binary a bundle that is not in your target. - open some type in the new project and attach source - select some type in the source and hit F3 (or ctrl-click) - notice that nothing happens I have verified that I am able to open type on the type that is selected and I am able to select the type name, hit ctrl-shift-T and have the open type dialog prepopulated with the type name. But just navigating directly does not work.
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
