Simple self-hosting is adequate for most standalone situations and is particularly well-suited to developing against the large products as targets. However, there are scenarios in which a more advanced solution is needed:
Since external plug-ins are not in the workspace, they are not part of the search scope. Therefore, various searches (for interface and class references, implementations etc.) return less results than expected. Only external libraries that are part of workspace plug-ins' class path are visible to Java plug-in.
Closely connected to 1), browsing source code of external plug-ins is only possible for plug-ins that are required by workspace plug-ins. Other plug-ins are not visible.
Class path is not stable. If you work on a number of interdependent plug-in in the workspace, PDE will express these dependencies as project references. In contrast, dependencies on external plug-ins will be expressed using ECLIPSE_HOME variable and external JARs. If these projects are shared using the repository, other developers will be forced to replicate this complement even though they do not necessarily need all the plug-ins you had in the workspace.
The obvious conclusion is that if all the plug-ins were in the workspace, these shortcomings would all be addressed. Search would work as expected, source code would be visible for all the classes and class path would be uniform i.e. would contain only project references. However, always adding the entire product from a shared repository in source form is prohibitively slow both for downloading and compilation. For this reason, a notion of binary projects is introduced.
Binary projects are regular plug-in projects that do not contain source code. As such, they are bypassed during compilation and are only used to address the shortcomings listed above. External plug-ins are brought into the workspace using the PDE import wizard.
Before importing binary projects, it is important to configure PDE for binary self-hosting. Since we will not use external plug-ins to resolved references, we should disable them in Preferences. After that, Import wizard is invoked using File->Import...->External Plug-ins and Fragments.
Most of the time, you will accept default values in the first page. By default, you are importing external plug-ins of the target run-time workbench as set in the Preferences. Alternatively, plug-ins from another locations can be imported.
When Next is pressed, the wizard will compute all import candidates and make them available in a list of checkboxes. The actual set of plug-ins you will select depends on the way you self-host.
If you are working on plug-ins that are not already present in the target platform, you will want to select all the choices (Select All). If some of the plug-ins on the list are already in the workspace in source form, you will want press Existing Projects, then Invert Selection. This will result in selecting all the plug-ins that are not in the workspace already.
When you press Finish, selected plug-ins will be imported into the workspace. PDE will also set their class path and associate source archives with libraries so that you can browse or debug them.
When there is a large number of binary projects in the workspace, it is hard to tell them apart from source projects. PDE provides two complementing ways to handle this problem. It provides for label decorator that adds a 'binary' icon overlay to the regular project icon to clearly mark the binary project. You can turn it on in Preferences under 'Workbench->Label Decorations'. In addition, PDE contributes binary project filter to Java Explorer view. When engaged, it will hide binary projects and leave only those you are working on.