development/porting/4.4/incompatibilities.html - www.eclipse.org/eclipse - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 <html lang="en">
 <head>
 <meta name="copyright" content="Copyright (c) 2014 IBM Corporation and others. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
 <meta http-equiv="Content-Style-Type" content="text/css">
 <link rel="STYLESHEET" href="../../book.css" charset="ISO-8859-1" type="text/css">
 <title>Incompatibilities between Eclipse 4.3 and 4.4</title>
 </head>

 <body>

 <h1>Incompatibilities between Eclipse 4.3 and 4.4</h1>

 <p>
   Eclipse changed in incompatible ways between 4.3 and 4.4 in ways that affect
   plug-ins. The following entries describe the areas that changed and provide
   instructions for migrating 4.3 plug-ins to 4.4. Note that you only need to look
   here if you are experiencing problems running your 4.3 plug-in on 4.4.
 </p>
 <p>
 See also the list of <a href="removals.html">deprecated API removals</a> for this release.
 </p>

 <ol>
 	<li><a href="#workspaceLock">Removed WorkspaceLock API</a></li>
 	<li><a href="#incrementalProjectBuilder_getRule">Removed IncrementalProjectBuilder#getRule() API</a></li>
 	<li><a href="#eclipse20PluginSupport">Removed built-in support for Eclipse 2.0 Plug-ins</a></li>
 	<li><a href="#equinoxFrameworkHooks">Equinox Framework Hook implementations must migrate</a></li>
 	<li><a href="#builtinOSGiConsole">Built-in Equinox OSGi console removed</a></li>
 </ol>

 <hr>

 <!-- ############################################## -->

 <h2>1. <a name="workspaceLock">Removed WorkspaceLock API</a></h2>
 <p><strong>What is affected:</strong> Clients that directly reference WorkspaceLock API.
 </p>
 <p><strong>Description:</strong>
 The <code>WorkspaceLock</code> API allowed a special client (usually platform UI) to
 hook into the locking protocols used by the workspace implementation. This hook
 was used to mitigate deadlocks due to interaction with synchronous SWT events,
 and was never intended to be used by other clients. In the 3.0 release this API
 was deprecated in favor of a more general API provided by the <code>org.eclipse.core.jobs</code>
 bundle. Invoking this API has had no effect since the 3.0 release. The specific API
 being removed includes:
 </p>
 <ul>
 <li>The <code>org.eclipse.core.resources.WorkspaceLock</code> class.</li>
 <li>The method <code>org.eclipse.core.resources.IWorkspace#setWorkspaceLock</code></li>
 </ul>
 <p><strong>Action required:</strong> Clients that directly use API listed above should remove any references to it.
 </p>

 <!-- ############################################## -->

 <h2>2. <a name="incrementalProjectBuilder_getRule">Removed IncrementalProjectBuilder#getRule() API</a></h2>
 <p><strong>What is affected:</strong> Clients that directly call or implement IncrementalProjectBuilder#getRule() API.
 </p>
 <p><strong>Description:</strong>
 The <code>IncrementalProjectBuilder#getRule()</code> method returned a scheduling rule
 that was required for building the project by the builder. This method was intended to be used by the builder framework only.
 In the 3.6 release this method was deprecated in favor of a more general method <code>IncrementalProjectBuilder#getRule(int, Map)</code>.
 The specific API being removed includes:
 </p>
 <ul>
 <li>The method <code>org.eclipse.core.resources.IncrementalProjectBuilder#getRule()</code></li>
 </ul>
 <p><strong>Action required:</strong> Clients that directly call API listed above should remove any references to it
 or replace with calls to <code>IncrementalProjectBuilder#getRule(int, Map)</code>. Clients that implement API listed
 above should implement <code>IncrementalProjectBuilder#getRule(int, Map)</code> instead.
 </p>

 <!-- ############################################## -->

 <h2>3. <a name="eclipse20PluginSupport">Removed built-in support for Eclipse 2.0 Plug-ins</a></h2>
 <p><strong>What is affected:</strong> Eclipse 2.0 plug-ins that have not migrated to an OSGi bundle.
 </p>
 <p><strong>Description:</strong>
 The 3.0 release migrated to a runtime based on the OSGi Framework specification.  In order to support
 the migration to OSGi bundles the Equinox OSGi Framework implementation provided support for
 transforming Eclipse 2.0 style plug-ins into real OSGi bundles at runtime.  This support is no longer
 provided by the Equinox Framework implementation.
 </p>
 <p><strong>Action required:</strong> Eclipse 2.0 plug-ins should be migrated to OSGi bundles.  For cases
 where Eclipse 2.0 plug-ins must be supported there is a compatibility fragment that can be installed
 (org.eclipse.osgi.compatibility.plugins).  This compatibility fragment must be installed in order
 to support the following:
 </p>
 <ul>
   <li>Run Eclipse 2.0 plug-ins on the 4.4 release</li>
   <li>Use PDE to develop Eclipse 2.0 plug-ins</li>
   <li>Use p2 to publish Eclipse 2.0 plug-ins to a repository </li>
 </ul>
 <!-- ############################################## -->

 <h2>4. <a name="equinoxFrameworkHooks">Equinox Framework Hook implementations must migrate</a></h2>
 <p><strong>What is affected:</strong> All Equinox Framework Hook implementations
 </p>
 <p><strong>Description:</strong>
 The Equinox Framework has a number of powerful framework specific hooks which framework fragments may
 implement in order to augment the behavior of the framework. These hooks are not considered API since
 they are closely tied to the internal implementation details of the framework. Attempts are made each
 release to support Equinox Framework hook implementations from previous releases.
 </p>
 <p><strong>Action required:</strong> The 4.4 release has changed much of the internal details of the
 Equinox Framework which required an overhaul of the Equinox implementation specific hooks.  As a result
 all existing Equinox Framework hook implementations will need to migrate. In most cases it should be
 possible to migrate existing hook implementations over to the new interfaces. Keep in mind that most of
 the internal types representing bundle have changed.
 </p>
 <!-- ############################################## -->

 <h2>5. <a name="builtinOSGiConsole">Built-in Equinox OSGi console removed</a></h2>
 <p><strong>What is affected:</strong> Usage of the built-in Equinox OSGi console
 </p>
 <p><strong>Description:</strong>
 Since the 3.0 release the Equinox Framework implementation has provided an OSGi console
 implementation. This console is useful for debugging the OSGi environment.  The 4.2 release
 disabled the built-in OSGi console included in the Equinox Framework
 (see <a href="../4.2/incompatibilities.html#osgiconsole">4.2 incompatibilities</a>).
 The 4.4 release has removed the built-in OSGi console completely from the Equinox Framework
 implementation.
 </p>
 <p><strong>Action required:</strong> In order to use the OSGi console, it is necessary to install
 the console bundle itself - org.eclipse.equinox.console and
 the three Gogo bundles - org.apache.felix.gogo.runtime,
 org.apache.felix.gogo.command, org.apache.felix.gogo.shell.
 Documentation for the Equinox console is available at
 <a href="../../guide/console_shell.htm"><b>Console Shell</b></a>. The configuration property
 <code>osgi.console.enable.builtin</code> no longer has any effect.
 </p>
 <!-- ############################################## -->
 </body>
 </html>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
	<html lang="en">
	<head>
	<meta name="copyright" content="Copyright (c) 2014 IBM Corporation and others. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >
	<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
	<meta http-equiv="Content-Style-Type" content="text/css">
	<link rel="STYLESHEET" href="../../book.css" charset="ISO-8859-1" type="text/css">
	<title>Incompatibilities between Eclipse 4.3 and 4.4</title>
	</head>

	<body>

	<h1>Incompatibilities between Eclipse 4.3 and 4.4</h1>

	<p>
	Eclipse changed in incompatible ways between 4.3 and 4.4 in ways that affect
	plug-ins. The following entries describe the areas that changed and provide
	instructions for migrating 4.3 plug-ins to 4.4. Note that you only need to look
	here if you are experiencing problems running your 4.3 plug-in on 4.4.
	</p>
	<p>
	See also the list of <a href="removals.html">deprecated API removals</a> for this release.
	</p>

	<ol>
	<li><a href="#workspaceLock">Removed WorkspaceLock API</a></li>
	<li><a href="#incrementalProjectBuilder_getRule">Removed IncrementalProjectBuilder#getRule() API</a></li>
	<li><a href="#eclipse20PluginSupport">Removed built-in support for Eclipse 2.0 Plug-ins</a></li>
	<li><a href="#equinoxFrameworkHooks">Equinox Framework Hook implementations must migrate</a></li>
	<li><a href="#builtinOSGiConsole">Built-in Equinox OSGi console removed</a></li>
	</ol>

	<hr>

	<!-- ############################################## -->

	<h2>1. <a name="workspaceLock">Removed WorkspaceLock API</a></h2>
	<p><strong>What is affected:</strong> Clients that directly reference WorkspaceLock API.
	</p>
	<p><strong>Description:</strong>
	The <code>WorkspaceLock</code> API allowed a special client (usually platform UI) to
	hook into the locking protocols used by the workspace implementation. This hook
	was used to mitigate deadlocks due to interaction with synchronous SWT events,
	and was never intended to be used by other clients. In the 3.0 release this API
	was deprecated in favor of a more general API provided by the <code>org.eclipse.core.jobs</code>
	bundle. Invoking this API has had no effect since the 3.0 release. The specific API
	being removed includes:
	</p>
	<ul>
	<li>The <code>org.eclipse.core.resources.WorkspaceLock</code> class.</li>
	<li>The method <code>org.eclipse.core.resources.IWorkspace#setWorkspaceLock</code></li>
	</ul>
	<p><strong>Action required:</strong> Clients that directly use API listed above should remove any references to it.
	</p>

	<!-- ############################################## -->

	<h2>2. <a name="incrementalProjectBuilder_getRule">Removed IncrementalProjectBuilder#getRule() API</a></h2>
	<p><strong>What is affected:</strong> Clients that directly call or implement IncrementalProjectBuilder#getRule() API.
	</p>
	<p><strong>Description:</strong>
	The <code>IncrementalProjectBuilder#getRule()</code> method returned a scheduling rule
	that was required for building the project by the builder. This method was intended to be used by the builder framework only.
	In the 3.6 release this method was deprecated in favor of a more general method <code>IncrementalProjectBuilder#getRule(int, Map)</code>.
	The specific API being removed includes:
	</p>
	<ul>
	<li>The method <code>org.eclipse.core.resources.IncrementalProjectBuilder#getRule()</code></li>
	</ul>
	<p><strong>Action required:</strong> Clients that directly call API listed above should remove any references to it
	or replace with calls to <code>IncrementalProjectBuilder#getRule(int, Map)</code>. Clients that implement API listed
	above should implement <code>IncrementalProjectBuilder#getRule(int, Map)</code> instead.
	</p>

	<!-- ############################################## -->

	<h2>3. <a name="eclipse20PluginSupport">Removed built-in support for Eclipse 2.0 Plug-ins</a></h2>
	<p><strong>What is affected:</strong> Eclipse 2.0 plug-ins that have not migrated to an OSGi bundle.
	</p>
	<p><strong>Description:</strong>
	The 3.0 release migrated to a runtime based on the OSGi Framework specification. In order to support
	the migration to OSGi bundles the Equinox OSGi Framework implementation provided support for
	transforming Eclipse 2.0 style plug-ins into real OSGi bundles at runtime. This support is no longer
	provided by the Equinox Framework implementation.
	</p>
	<p><strong>Action required:</strong> Eclipse 2.0 plug-ins should be migrated to OSGi bundles. For cases
	where Eclipse 2.0 plug-ins must be supported there is a compatibility fragment that can be installed
	(org.eclipse.osgi.compatibility.plugins). This compatibility fragment must be installed in order
	to support the following:
	</p>
	<ul>
	<li>Run Eclipse 2.0 plug-ins on the 4.4 release</li>
	<li>Use PDE to develop Eclipse 2.0 plug-ins</li>
	<li>Use p2 to publish Eclipse 2.0 plug-ins to a repository </li>
	</ul>
	<!-- ############################################## -->

	<h2>4. <a name="equinoxFrameworkHooks">Equinox Framework Hook implementations must migrate</a></h2>
	<p><strong>What is affected:</strong> All Equinox Framework Hook implementations
	</p>
	<p><strong>Description:</strong>
	The Equinox Framework has a number of powerful framework specific hooks which framework fragments may
	implement in order to augment the behavior of the framework. These hooks are not considered API since
	they are closely tied to the internal implementation details of the framework. Attempts are made each
	release to support Equinox Framework hook implementations from previous releases.
	</p>
	<p><strong>Action required:</strong> The 4.4 release has changed much of the internal details of the
	Equinox Framework which required an overhaul of the Equinox implementation specific hooks. As a result
	all existing Equinox Framework hook implementations will need to migrate. In most cases it should be
	possible to migrate existing hook implementations over to the new interfaces. Keep in mind that most of
	the internal types representing bundle have changed.
	</p>
	<!-- ############################################## -->

	<h2>5. <a name="builtinOSGiConsole">Built-in Equinox OSGi console removed</a></h2>
	<p><strong>What is affected:</strong> Usage of the built-in Equinox OSGi console
	</p>
	<p><strong>Description:</strong>
	Since the 3.0 release the Equinox Framework implementation has provided an OSGi console
	implementation. This console is useful for debugging the OSGi environment. The 4.2 release
	disabled the built-in OSGi console included in the Equinox Framework
	(see <a href="../4.2/incompatibilities.html#osgiconsole">4.2 incompatibilities</a>).
	The 4.4 release has removed the built-in OSGi console completely from the Equinox Framework
	implementation.
	</p>
	<p><strong>Action required:</strong> In order to use the OSGi console, it is necessary to install
	the console bundle itself - org.eclipse.equinox.console and
	the three Gogo bundles - org.apache.felix.gogo.runtime,
	org.apache.felix.gogo.command, org.apache.felix.gogo.shell.
	Documentation for the Equinox console is available at
	<a href="../../guide/console_shell.htm"><b>Console Shell</b></a>. The configuration property
	<code>osgi.console.enable.builtin</code> no longer has any effect.
	</p>
	<!-- ############################################## -->
	</body>
	</html>