Community
Participate
Working Groups
With the addition of the PDE classpath containers, I no longer have to have all the world in my workspace. THANK YOU. However, there does not seem to be an easy way to search the code in the target. So, for example, one cannot easily see how/if people are using a class, method, ...
Jeff, there is a view in PDE perspective called 'Plugins'. You can use the perspective or add the view into your favorite one. The view shows all the plug-ins that PDE sees. The goal is to 'extend' the Navigator/Packages into the target platform. Here is what you can do: 1) Browse and open files 2) Drag files and folders from external plug-ins into the workspace 3) Copy/paste (mostly the same code as 2 :-) 3) Select plug-in(s) and import it into the workspace 4) Select plug-in(s) and use command 'Add to Java search' from the pop-up menu I guess you are insterested in 4). There are some limitations with this function but it does work. What we do is create a 'proxy' project in the workspace and add jars of the external plug-ins as 'external JARs'. No files are copied in the process - we just change the classpath. This makes the classes in the JARs visible to Java model. The downside compared to binary projects is loss of context (JDT guys can explain it better :-). Not very many people used this function until now, but if it turns out to be useful, we may work with JDT team to find ways of improving it. A more natural way would be to extend Packages view to 'see' external plug-ins (have a notion of virtual IJavaProject without underlying IProject), but that is so post 3.0.
Note that we didn't want to duplicate Packages/Navigator view. If a plug-in is in the workspace, it will show with the project icon and you will not be able to browse (why doing it there when you can do it in the Packages). Instead, we have an action 'Show in Packages' on the pop-up menu. Since these objects are just stand-ins for projects in the workspace, you can elect to filter them out (from the view's pull-down menu).
Great. I like this idea. In fact, I like it so much it should be more visible, available. I never use the plugin view/perspective so did not know aobut this. I suggest you add this to say the target platform pref page as a check box "add target plugins to java search" or some such. I just want them all, all the time. Having said that, there is still a problem. I followed the steps and could hten open type on things from the target plugins. But if I select a method in my source project and look for references, the references in the target plugins are not found. I assume that this is a problem with java search and have entered https://bugs.eclipse.org/bugs/show_bug.cgi?id=52667 Without this working, there is no easy way for someone to avoid breaking/understanding other people's use of their code other than loading all the projects in to the workspace as binary (or source). Bummer.
For your bedtime reading, bug 27472 goes over some of the Plugins view limitations and java search is one of them.
*** Bug 57116 has been marked as a duplicate of this bug. ***
Fixed by doing the following: 1) Reworked 'External Plug-in Libraries' project to use classpath container for libraries added to Java search in Plug-ins view (thus making it dynamic - no manual maintenance required) 2) Added workspace plug-in projects onto the dynamic classpath to support reference searches
