View All Attachments for Bug 126575

Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Attachment #52976
Resolution plan	text/html	2006-10-31 05:25:47 EST	4.17 KB	no flags	Details

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>bugzilla_126575 Resolution Plan</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">
<!--
li {
	list-style-type: lower-alpha;
}
-->
</style>
</head>

<body>
<h1>bugzilla_126575 Resolution Plan</h1>
<p>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.</p>
<p> The resolution falls under three categories:</p>
<ol>
  <li>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.</li>
  <li> 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.</li>
  <li> 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. </li>
</ol>
<h4><br>
  1) PDE Model access: PDE has accepted to publish APIs that give equivalent information 
  to these internal APIS:</h4>
<p>- PDECore.getDefault().getModelManager().getWorkspaceModels()<br>
  - PDECore.getDefault().getModelManager().getExternalModels()<br>
  - PDECore.getDefault().getModelManager().findModel(IProject)<br>
  - PDECore.getDefault().getModelManager().getPlugins()</p>
<p>Solution: TPTP code will be migrated to use public APIs.<br>
  When: <strong>TBD</strong> (when PDE makes these APIs available). An intermediate 
  check-point will be performed when API details are available.</p>
<h4>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)</h4>
<p>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.<br>
  When: <strong>4.3i3</strong></p>
<h4>3) WorkspacePluginModelBase.save(PrintWriter)</h4>
<p>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.<br>
  When: <strong>4.4</strong>.</p>
<h4>4) ExternalModelManager.getEclipseHome()</h4>
<p>Solution: We will use JavaCore.getClasspathVariable(&quot;ECLIPSE_HOME&quot;) 
  instead.<br>
  When: <strong>4.3i3</strong>.</p>
<h4>5) TargetPlatform.getOS()<br>
  6) TargetPlatform.getOSArch()<br>
  7) TargetPlatform.getWS()<br>
  8) TargetPlatform.getNL()<br>
  9) TargetPlatform.getApplicationNames()<br>
  10) TargetPlatform.getDefaultProduct()</h4>
<p>Solution: PDE intends to publish these APIs.<br>
  When: <strong>TBD</strong> (As soon as the public APIs are available)</p>
<h4>11) TargetPlatform.createPlatformConfigurationArea(Map, File, String)<br>
  12) TargetPlatform.getConfigIniProperties(String)</h4>
<p>PDE suggested that we copy these methods, as they are very self-contained. 
  We will do so.<br>
  When: <strong>4.4</strong></p>
<h4>13) PDEPlugin.getDefault().getLabelProvider()</h4>
<p>Solution: we will implement our own label provider for representing plugins. 
  This includes copying a few icons from PDE.<br>
  When: <strong>4.4</strong></p>
<h4>14) ListUtil.PLUGIN_SORTER</h4>
<p>Solution: we will implement our own sorter for sorting IPluginModel objects.<br>
  When: <strong>4.4</strong></p>
<h4>15) org.eclipse.ui.internal.ide.misc.ResourceAndContainerGroup;</h4>
<p>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.<br>
  When: <strong>4.3i3</strong>.<br>
</p>
</body>
</html>

Attachment #52989
Fix for items 2, 4 and 15 (see resolution plan)	patch	2006-10-31 09:20:27 EST	40.30 KB	no flags	Details

Attachment #53130
Fix for item 13 (see resolution plan)	patch	2006-11-02 08:40:13 EST	13.14 KB	no flags	Details

Attachment #53134
Fix for item 14 (see resolution plan)	patch	2006-11-02 08:51:04 EST	4.10 KB	no flags	Details

Attachment #56762
Updated fix for item 13 (see resolution plan)	patch	2007-01-11 09:22:30 EST	10.64 KB	no flags	Details

Attachment #56805
Updated Resolution Plan	text/html	2007-01-11 17:36:28 EST	4.70 KB	no flags	Details

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><title>bugzilla_126575 Resolution Plan</title>



<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">
<!--
li {
	list-style-type: lower-alpha;
}
-->
</style></head><body>
<h1>bugzilla_126575 Resolution Plan</h1>
<p>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.</p>
<p> The resolution falls under three categories:</p>
<ol>
  <li>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.</li>
  <li> 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.</li>
  <li> 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. </li>
</ol>
<h4><br>
  1) PDE Model access: PDE has accepted to publish APIs that give equivalent information 
  to these internal APIS:</h4>
<p>- PDECore.getDefault().getModelManager().getWorkspaceModels()<br>
  - PDECore.getDefault().getModelManager().getExternalModels()<br>
  - PDECore.getDefault().getModelManager().findModel(IProject)<br>
  - PDECore.getDefault().getModelManager().getPlugins()</p>
<p>Solution: TPTP code will be migrated to use public APIs.<br>
  When: <strong>TBD</strong> (when PDE makes these APIs available). An intermediate 
  check-point will be performed when API details are available.</p>
<h4>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)</h4>
<p>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.<br>
  When: <strong>4.3i3</strong></p>
<h4>3) WorkspacePluginModelBase.save(PrintWriter)</h4>
<p>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.<br>
  When: <strong>4.4</strong>.</p>
<h4>4) ExternalModelManager.getEclipseHome()</h4>
<p>Solution: We will use JavaCore.getClasspathVariable("ECLIPSE_HOME") 
  instead.<br>
  When: <strong>4.3i3</strong>.</p>
<h4>5) TargetPlatform.getOS()<br>
  6) TargetPlatform.getOSArch()<br>
  7) TargetPlatform.getWS()<br>
  8) TargetPlatform.getNL()<br>
  9) TargetPlatform.getApplicationNames()<br>
  10a) TargetPlatform.getDefaultProduct()<br>
  10b) TargetPlatform.getBundleList()<br>
  10c) TargetPlatform.getProductNames()</h4>
<p>Solution: PDE intends to publish these APIs.<br>
  When: <strong>TBD</strong> (As soon as the public APIs are available)</p>
<h4>11) TargetPlatform.createPlatformConfigurationArea(Map, File, String)<br>
  12a) TargetPlatform.getConfigIniProperties(String)<br>
  12b) TargetPlatform.getConfigIniProperties()</h4>
<p>PDE suggested that we copy these methods, as they are very self-contained. 
  We will do so.<br>
  When: <strong>4.4</strong></p>
<h4>13) PDEPlugin.getDefault().getLabelProvider()</h4>
<p>Solution: we will implement our own label provider for representing plugins. 
  This includes copying a few icons from PDE (frgmt_obj.gif, plugin_obj.gif and external_co.gif).<br>
  When: <strong>4.4</strong></p>
<h4>14) ListUtil.PLUGIN_SORTER</h4>
<p>Solution: we will implement our own sorter for sorting IPluginModel objects.<br>
  When: <strong>4.4</strong></p>
<h4>15) org.eclipse.ui.internal.ide.misc.ResourceAndContainerGroup;</h4>
<p>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.<br>
  When: <strong>4.3i3</strong>.<br>
</p>
<h4>16) Creating an instance of a org.eclipse.pde.internal.core.build.WorkspaceBuildModel to load a build.properties file.</h4>
<p>Solution: PDE will not provide us with an API and has suggested the following work-around: a DOM will be constructed from the build.properties, modified in memory, and saved to a new XML file.<br>
  When: <strong>4.4</strong>.<br>
</p>
</body></html>