Community
Participate
Working Groups
Build Identifier: Eclipse 3.7.1 AS IS: Have a plugin project with dependency on org.eclipse.core.resources. Open org.eclipse.core.internal.resources.WorkspaceRoot class. Go to findFilesForLocation() method which looks like: public IFile[] findFilesForLocation(IPath location) { return findFilesForLocationURI(URIUtil.toURI(location.makeAbsolute())); } Now do a Ctrl+Click on toURI() method call. org.eclipse.core.resources.URIUtil is opened. TO BE: Unfortunately, org.eclipse.core.resources.URIUtil is wrong class to open! org.eclipse.core.filesystem.URIUtil must be opened instead. Looking at the import list in the file one can see this: import org.eclipse.core.filesystem.URIUtil; import org.eclipse.core.internal.utils.FileUtil; import org.eclipse.core.internal.utils.Policy; import org.eclipse.core.resources.*; So it looks like the editor action to open the method declaration simply looks first into the last import line, and does not consider the first one. Reproducible: Always
I can reproduce using 3.7.2. However, this works using the latest 4.2 build (I20120321-0610). I think this got fixed along with bug 318401. Moving to JDT/Core for confirmation.
Using 3.8M6, the toURI call resolves to org.eclipse.core.runtime.URIUtil.toURI(URL) Strange. I will take a look.
(In reply to comment #2) > Using 3.8M6, the toURI call resolves to > org.eclipse.core.runtime.URIUtil.toURI(URL) > Strange. I will take a look. Andrey, can you confirm if you see org.eclipse.core.resources.URIUtil or org.eclipse.core.runtime.URIUtil? Analysing a bit more, according to JLS 6.4.1 "A single-type-import declaration d in a compilation unit c of package p that imports a type named n shadows, throughout c, the declarations of: • any top level type named n declared in another compilation unit of p • any type named n imported by a type-import-on-demand declaration in c • any type named n imported by a static-import-on-demand declaration in c" So, in WorkspaceRoot, org.eclipse.core.filesystem.URIUtil should be the type available.
(In reply to comment #3) > Andrey, can you confirm if you see org.eclipse.core.resources.URIUtil or > org.eclipse.core.runtime.URIUtil? org.eclipse.core.runtime.URIUtil Sorry I have no idea how I got org.eclipse.core.resources.URIUtil in the original bug description. It should be: TO BE: Unfortunately, org.eclipse.core.runtime.URIUtil is wrong class to open! org.eclipse.core.filesystem.URIUtil must be opened instead.
This is most probably an effect of bug 73957. If WorkspaceRoot#findFilesForLocation(IPath) is a binary class, then it may have compile errors (which are not shown, since the class file is already compiled, but you can see them e.g. in the AST View). In a fresh workspace with a single bundle that only requires org.eclipse.core.runtime and org.eclipse.core.resources, the org.eclipse.core.filesystem bundle is missing from the classpath. Therefore, the resolution fails, and as a fallback, we just try to match the simple name (the guess being that the import could be wrong). Deepak, could that explain the difference in comment 1 (i.e. do you have org.eclipse.core.resources in source in your 4.2 workspace or did the plug-in from which you opened WorkspaceRoot also require org.eclipse.core.filesystem)?
(In reply to comment #5) Ha! That explains what Ayush and I were observing yesterday. > Deepak, could that explain the difference in comment 1 (i.e. do you have > org.eclipse.core.resources in source in your 4.2 workspace or did the plug-in > from which you opened WorkspaceRoot also require org.eclipse.core.filesystem)? I do not have org.eclipse.core.resources in source. WorkspaceRoot is opened from 'External Plug-in Libraries' which obviously has org.eclipse.core.filesystem as well :-)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
