bugzilla_128262 Resolution Plan

The following documents contains an up-to-date list (as of 4.3i2) of PDE internal APIs that are still in use by TPTP, and the associated plan to remove these dependencies.

The resolution falls under three categories:

  1. PDE intends to provide public APIs for the requested feature. In this case, instances of calls to such internal APIs will be maintained in TPTP until the PDE APIs are published.
  2. PDE does not intend to provide public APIs, and there is a simple work-around, that does not involve more than 10 lines changes. For such instances, TPTP code will be migrated by the end of 4.3i3.
  3. PDE does not intend to provide public APIS, and there is a more elaborate work-around that involves more than 10 lines changes. For such instances, TPTP code will be migrated by the end of 4.4.


1) PDE Model access: PDE has accepted to publish APIs that give equivalent information to these internal APIS:

- PDECore.getDefault().getModelManager().getWorkspaceModels()
- PDECore.getDefault().getModelManager().getExternalModels()
- PDECore.getDefault().getModelManager().findModel(IProject)
- PDECore.getDefault().getModelManager().getPlugins()

Solution: TPTP code will be migrated to use public APIs.
When: TBD (when PDE makes these APIs available). An intermediate check-point will be performed when API details are available.

2) ability to test whether a IPluginModelBase instance is a bundle-based or plugin-based plugin model (this is currently done by checking model instanceof BundlePluginModelBase or model instanceof WorkspacePluginModelBase)

Solution: PDE has no intent to provide us with such an API. We will apply the suggested work-around, which consists in testing whether is a META-INF/MANIFEST.MF file exists in a plugin's project.
When: 4.3i3

3) WorkspacePluginModelBase.save(PrintWriter)

Solution: PDE will not provide us with an API and has suggested the following work-around: a DOM will be constructed from the plugin.xml, modified in memory, and saved to a new XML file.
When: 4.4.

4) ExternalModelManager.getEclipseHome()

Solution: We will use JavaCore.getClasspathVariable("ECLIPSE_HOME") instead.
When: 4.3i3.

5) TargetPlatform.getOS()
6) TargetPlatform.getOSArch()
7) TargetPlatform.getWS()
8) TargetPlatform.getNL()
9) TargetPlatform.getApplicationNames()
10) TargetPlatform.getDefaultProduct()

Solution: PDE intends to publish these APIs.
When: TBD (As soon as the public APIs are available)

11) TargetPlatform.createPlatformConfigurationArea(Map, File, String)
12) TargetPlatform.getConfigIniProperties(String)

PDE suggested that we copy these methods, as they are very self-contained. We will do so.
When: 4.4

13) PDEPlugin.getDefault().getLabelProvider()

Solution: we will implement our own label provider for representing plugins. This includes copying a few icons from PDE.
When: 4.4

14) ListUtil.PLUGIN_SORTER

Solution: we will implement our own sorter for sorting IPluginModel objects.
When: 4.4

15) org.eclipse.ui.internal.ide.misc.ResourceAndContainerGroup;

Solution: This class is referenced by the RunWizard, which is an internal class, and is no longer used in TPTP (no reference from code, nor from plugin.xml). The RunWizard, and its associated pages, RunDestinationPage, and RunLocationPage will be removed.
When: 4.3i3.