Community
Participate
Working Groups
i200405130010 This is probably known, but... for new-style plug-in manifests (like core.runtime's), that do not contain a plug-in identifier, searching for references to any of its extension points fails to find any results.
Using RC1, I searched for extension points/extensions starting with org.eclipse.core.runtime.* and I got all the correct hits including the ones in the plugin.xml of org.eclipse.core.runtime.
Actually, there is certainly a problem. Whe I closed the defect as worksforme, I had verified that searching for references to an extension point such as "org.eclipse.core.runtime.applications" is fine through the Search page and it was. The problem here is when you do it in the plugin manifest editor, you will get 0 references. This is because when we do a search for a reference to an extension point, we implicitly prepend the id of the plugin. So in this case, when selecting "applications", we ask its model for its id, which should return "org.eclipse.core.runtime". When the editor is open however, the extension point comes from the plugin.xml that contains no plugin id, so when we ask the model for the plugin.xml for its id, it returns null, and hence no search hits are found. Need to investigate the value/risk ratio. I can't believe this one fell through the cracks.
Reopening...
That makes bug 68119 a duplicate of this one, doesn't it?
looks like a readme bug
*** Bug 68119 has been marked as a duplicate of this bug. ***
To do a proper fix is too risky and too elaborate. It becomes an extremely difficult problem to solve properly when opening the plugin.xml on an external file using the Plugins view. There are workarounds as described in bug 68119. One workaround that PDE could do and would require a one-character change in our code is to prepend '*' to the search string if a plugin id is null. So the search string would be '*.applications', which would pick up all the hits. This, of course, would be error-prone if more than one extension point had the same id, and yet they were declared by different plugins. So it's either a README or the '*' change. Dejan, thoughts?
When I perform a Java search for a method, sometimes I get lots of hits - method with the same name in unrelated classes. In other words, I have seen Java search give me more results than I need i.e. not very precise. I would rather have that than 0 hits. I vote for '*'. Can you try it out and give it a test using real-world extension point. We need to find out how frequently will the users get the 'false' hits.
In the Eclipse SDK as it is today, you would get 0 false hits.
I know :-). Please use the '*' workaround in your workspace and try some searches.
comment #9 was not a conjecture/prediction. It was based on me testing the '*' change. So the sensible thing to do is to do this minor change and add a README entry, that there is a theoretical possibility the search might return a false hit if two plug-ins that both use a manifest.mf happen to declare an extension point by the same id.
I will attach the patch very shortly. We're soliciting for two votes for RC4. Dejan? Jeff?
+1
Created attachment 12619 [details] Patch for pde-ui Dejan and Cherie, please review patch.
Verified. +1
Patch looks good - +1.
Marking as fixed.
