platform/4.3/final/eclipse-news-part4.html - platform/eclipse.platform.news - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 <html>
 <head>
 <meta name="copyright" content="Copyright (c) Eclipse contributors and others 2013. This page is made available under license. For full details, see the LEGAL section in the documentation that contains this page."/>
 <meta http-equiv="Content-Language" content="en-us"/>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
 <link rel="stylesheet" href="default_style.css" charset="ISO-8859-1" type="text/css"/>
 <style type="text/css">
 table.news td {border-top: solid thin black;}
 table.news tr {vertical-align: top;}
 table.news tr td.section {font-size: 20px; font-weight: bold;}
 table.news tr td.title {vertical-align: top; width: 30%; font-weight: bold;}
 table.news tr td.content {vertical-align: top; width: 70%;}
 </style>
 <title>Eclipse Project Kepler - New and Noteworthy</title>
 </head>
 <body>
 <div style="font-size: 20px; font-weight: bold;">Plug-in Development Environment</div>

 <!-- ****************** START OF N&N TABLE ****************** -->
 <table class="news" cellpadding="10" cellspacing="0">
   <tbody>

   <!-- ******************** APITools ********************** -->
   <tr>
     <td id="APITools" class="section" colspan="2"><h2>API Tools</h2></td>
   </tr>

   <tr id="ee-desc-feature">
     <td class="title">New API Tools EE descriptions feature</td>
     <td class="content">
       The API Tools Execution Environment descriptions are now supplied on the Eclipse update sites as a single
       installable feature.  The feature includes the descriptions for all supported execution environments.

        <p><img src="images/eedescfeature.png" alt="New EE Desc feature on update sites"/></p>
     </td>
   </tr>

     <tr id="noreference-types">
     <td class="title">API Tools allows @noreference Javadoc tag on types</td>
     <td class="content">
       API Tools now allows the use of the <code>@noreference</code> Javadoc tag on types (classes, interfaces,
       annotations and enums).
       <p><img src="images/no-reference.png" alt="Type defining noreference Javadoc tag"/></p>
       <p>Placing this tag restricts the API so that any reference to that type or its members
       will be flagged as invalid API use.</p>
       <p><img src="images/using-no-reference.png" alt="Class trying to reference a type marked as noreference"/></p>
       <p>
       To mark a type in an API package as not being API, tag it as <code>@noreference</code>,
       <code>@noextend</code> and <code>@noinstantiate</code> (or <code>@noimplement</code>).  This ensures that
       no client can access it via valid API and the type could later be removed.
       </p>
     </td>
   </tr>

     <tr id="api-tags-check-visibility">
     <td class="title">API Tools Javadoc tags check visibility</td>
     <td class="content">
       A member that is not publicly visible, such as a method or field marked private, is not part
       of API.  Any API Tools Javadoc tags on it are invalid.  Now, API Tools will also check if a
       member is not visible because of the visibility of an enclosing type.  If the member is not visible,
       any tags on it will be considered invalid.
       <p><img src="images/api-parent-not-visible.png" alt="Javadoc tag flagged as invalid because member is not visible"/></p>
       <p>
       Tag validation is turned off by default.  To turn it on for your API Tools enabled project, open
       <b>Project Properties > Plug-in Development > API Errors/Warnings</b>.  Set
       <b>API Use > General > Unsupported use of API Javadoc tags</b> to <code>Warning</code> or <code>Error</code>.
       </p>
     </td>
   </tr>

   <tr id="support-pre-osgi-bundles">
     <td class="title">API Tools has limited support for pre-OSGi Eclipse plug-ins</td>
     <td class="content">
       Eclipse plug-ins created before 3.1 did not contain an OSGi bundle manifest.  API Tools
       can now convert the pre-OSGi plug-ins to valid components in an API baseline.  This allows
       analysis, use and freeze scans to process plug-ins that depend on pre-OSGi plug-ins instead
       of failing to resolve.
       <p><img src="images/use-scan.png" alt="Use scan launch configuration with pre-OSGi plug-ins"/></p>
       <p>
       An OSGi runtime is required to do the conversion.  Tasks run using Eclipse AntRunner
       or the API Use Report external tools launch configuration can convert the plug-ins.  Tasks
       run from the command line Ant runner will skip pre-OSGi plug-ins.
       </p>
     </td>
   </tr>

   <tr id="api-unresolved-bundles">
    <td class="title">API Tools Analysis and Freeze tasks can run with unresolved bundles</td>
    <td class="content">
 	 The API Tools <b>Analysis</b> and <b>API Freeze</b> Ant tasks will now process bundles
 	 with resolver errors such as missing dependencies.  This means you can now get analysis results
 	 for an incomplete product.
 	 <p>
      The Ant tasks produce reports based on a reference baseline and a profile.  Previously both
      the baseline and the profile had to describe complete products.  Any bundle that had resolver
      errors due to missing dependencies would be skipped.  Now these bundles will be processed.
      </p>
      <p>
      Resolver errors can affect the results, therefore a list of resolver errors is included in the XML output
      and warnings are added to the HTML report. To return to the old behavior of skipping
      unresolved bundles, you can set <code>processunresolvedbundles="false"</code> on your Ant task.
      </p>
      <p>
      <img src="images/unresolved-analysis.png" alt="Unresolved bundle in the analysis task"/>
      </p>
    </td>
   </tr>

   <tr id="api-use-filters">
     <td class="title">Problem filters apply to API Tools use scans</td>
     <td class="content">
       Problem filter files (.api_filter) can be used to filter problems reported by the API Tools analysis
       task and the workspace analysis builder.  These filter files can now be applied to API Tools use scans.
       Reference problems that are filtered out of the analysis results can also be filtered from the results
       of use scans.
       <p>
       Filters are specified in the task using the same property as the analysis task.  Set the <em>filters</em>
       attribute on the <em>apitooling.apiuse</em> task, specifying the root directory of API filter files.  Each
       filter file must be in a folder with a filename matching the component name the filter file applies to.
       </p>
     </td>
   </tr>

   <tr id="missing-filters-on-tasks">
     <td class="title">API Tools tasks warn about missing include or exclude files</td>
     <td class="content">
       Many of the API Tools tasks, including Analysis, API Use, and API Freeze, provide <em>includelist</em> and
       <em>excludelist</em> attributes which can be used to limit the reported problems. Previously,
       if you set an include or exclude list, but the file wasn't found, the task would continue without warning
       about the incorrect filtering.  Now a missing include or exclude list will result in the task failing with
       an explanation.
       <p>
       <img src="images/missing-include.png" alt="Example console output for missing include"/>
       </p>
     </td>
   </tr>

   <!-- ******************** Views and Editors ********************** -->
   <tr>
     <td id="ViewsAndEditors" class="section" colspan="2"><h2>Views and Editors</h2></td>
   </tr>

   <tr id="improved-feature-selection">
     <td class="title">Improved feature selection dialog</td>
     <td class="content">
       The feature selection dialog used in wizards and editors has been enhanced with better wildcard support
       and filtering options.

        <p><img src="images/featureselection.png" alt="Improved feature selection dialog"/></p>
     </td>
   </tr>

   <tr id="additional-type-info">
     <td class="title">Javadoc hover available in plug-in manifest editor</td>
     <td class="content">
       When editing the plugin.xml or manifest.mf files using the <b>Plug-in Manifest Editor</b>,
       opening content assist for type proposals will now display additional Javadoc information.
       <p>
         <img src="images/additional-type-info.png" alt="Additional info Javadoc hover for type proposals"/>
       </p>
     </td>
   </tr>

   <tr id="import-package">
     <td class="title">New import package quick fixes</td>
     <td class="content">
       New quick fixes are available when you have an unresolved type in a Java file.  If the unresolved type
       can be found in a package exported by a plug-in, a quick fix will be available to add an import
       package entry to your plug-in manifest.  There is also a quick fix to add the exporting plug-in to
       your manifest's require bundle header.
       <p>
       <img src="images/import-package.png" alt="Import package quick fix on an unresolved type"/>
       </p>
       <p>
       If a package providing the type is available but the package is not exported by its plug-in, a quick fix will
       offer to fix the providing plug-in's manifest. Only plug-ins in the workspace can be modified this
       way.
       </p>
       <p>
       <img src="images/export-package.png" alt="Export package quick fix on an unresolved type that is not exported"/>
       </p>
     </td>
   </tr>

   <tr id="bundles-in-category-editor">
     <td class="title">Bundles in the category editor</td>
     <td class="content">
       The category editor now supports putting individual bundles into categories.
       <p>
       The category editor creates a category.xml that can define categories that the contents of
       a p2 repository should be organized into.  Previously only features could be specified as belonging
       to a category and be visible to users.  Now individual bundles can be added to the category.xml.
       </p>
       <p>
       <img src="images/category-editor.png" alt="Category editor can include individual bundles"/>
       </p>
     </td>
   </tr>

   <tr id="plugin-image-view">
     <td class="title">Plug-in image browser view</td>
     <td class="content">
       A new view has been added to PDE.  The <b>Plug-in Image Browser</b> view displays icons and other
       images from your target platform, running application or current workspace.
       <p>
       	When an image is selected, additional information is displayed at the bottom of the view.  The
         reference text can be used in plug-in extensions to refer to images in other bundles.
       </p>
       <p>
         <img src="images/plugin-image-view.png" alt="The plug-in image browser view"/>
       </p>
     </td>
   </tr>

   <!-- ******************** Misc ********************** -->
   <tr>
     <td id="Misc" class="section" colspan="2"><h2>Misc</h2></td>
   </tr>

   <tr id="default-launch-ee">
     <td class="title">Launch configurations choose default execution environment</td>
     <td class="content">
       New PDE launch configurations (Eclipse Application, JUnit Plug-in Test, OSGi Framework) will
       use a default execution environment to determine which Java runtime environment to launch with.
       The launch configuration can be changed to use a different execution environment or a specific
       JRE on the <b>Main</b> tab.
       <p>
         To find a valid execution environment, all known environments are checked against each bundle
         or plug-in that will be launched. Only an execution environment that is valid for all
         plug-ins and bundles will be selected.  If no valid environment is found, a default JRE
         will be chosen as before.
       </p>
       <p>
         <img src="images/default-launch-ee.png" alt="Java runtime settings on the Main tab of PDE launch configurations"/>
       </p>
       <p>
       	The JRE associated with the selected execution environment will be used to launch. To change
       	which JRE is associated with an execution environment, use the <b>Preferences > Java > Installed JREs >
       	Execution Environments</b> preference page.
       </p>
     </td>
   </tr>

   <tr id="pde-5-bree">
     <td class="title">PDE UI requires a 1.5 EE</td>
     <td class="content">
       The bundle required execution environment for the PDE UI bundles org.eclipse.pde.core and
       org.eclipse.pde.ui is now J2SE-1.5.
     </td>
   </tr>

   <tr id="plugin-classpath-contributors">
     <td class="title">New API to contribute to the classpath of plug-in projects</td>
     <td class="content">
       New API in PDE allows you to add additional classpath entries to a plug-in project.  Contribute a
       <em>Plug-in Classpath Contributor</em> via the <em>org.eclipse.pde.core.pluginClasspathContributors</em>
       extension point.  Whenever the PDE classpath is computed or a new plug-in dependency is added, your classpath
       contributor will be queried for additional entries.
       <p>
       If you are using Equinox Adapter hooks to load additional libraries at runtime you can use this API to add
       the correct libraries to the classpath at build time.
       </p>
       <p>
       <img src="images/classpath-contributor.png" alt="An example classpath contributor extension"/>
       </p>
       </td>
   </tr>

   <tr id="update-classpath-workspace">
     <td class="title">Updating the classpath requires a workspace lock</td>
     <td class="content">
       When a change is made to a plug-in that forces a classpath update, an update job is created that
       modifies the Plug-in Dependencies classpath container in the background. This job now acquires a workspace lock
       to prevent other operations such as builders from running on a stale classpath.
       <p>
       This behaviour can be enabled in 4.2.2 by setting the system property <em>pde.lockWorkspaceForClasspath</em> to
       true.
       </p>
     </td>
   </tr>

   <tr id="auto-start-all-plugins">
     <td class="title">Default start level settings apply to all plug-ins</td>
     <td class="content">
       When editing the <b>Plug-ins</b> tab of an <b>Eclipse Application</b> launch configuration, the <b>Default
       Start level</b> and <b>Default Auto-start</b> settings chosen at the top of the tab will be used when launching with
       all workspace and enabled target plug-ins.  Previously this setting would only be used when launching a
       specific list of plug-ins.
       <p><img src="images/autostart-all-plugins.png" alt="All plug-ins selected on the tab"/></p>
       <p><img src="images/autostart-levels.png" alt="Different default start level settings"/></p>
     </td>
   </tr>

   <tr id="pde-run-remembers-selection">
     <td class="title">Running from PDE editors remembers previous launch</td>
     <td class="content">
       The PDE editors allow applications to be launched from the top toolbar of the <b>Manifest</b>, <b>Plug-in</b>
       and <b>Product</b> editors.  By default PDE only provides one type of application to launch.  However, if you have additional tooling
       installed such as RAP Tools, different application launches will be available in a drop down menu.
       <p><img src="images/launch-order.png" alt="Ordering of launches in editor"/></p>
       <p>
       This menu now remembers which application was launched most recently and puts it at the top of the list.  The most
       recent choice will be launched if the run button is pressed.  The order is saved between workbench
       restarts.
       </p>
     </td>
   </tr>

   <tr id="pde-junit-e4">
     <td class="title">JUnit plug-in tests can run on Eclipse platform 4 workbench</td>
     <td class="content">
       Applications that use the Eclipse Platform 4 workbench API can now
       use <b>JUnit Plug-in Test</b> launch configurations to test their plug-ins. Previously
       the tests would require the 3.x workbench API from the <code>org.eclipse.ui</code> bundle to
       hook into the workbench lifecycle.
     </td>
   </tr>

   <!-- ****************** END OF N&N TABLE ****************** -->
   </tbody>
 </table>

 <p align="center"><a href="eclipse-news-part3.html">Previous</a>&nbsp;&nbsp;&nbsp;&nbsp; <font color="#808080">Next</font></p>

 </body>
 </html>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
	<html>
	<head>
	<meta name="copyright" content="Copyright (c) Eclipse contributors and others 2013. This page is made available under license. For full details, see the LEGAL section in the documentation that contains this page."/>
	<meta http-equiv="Content-Language" content="en-us"/>
	<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
	<link rel="stylesheet" href="default_style.css" charset="ISO-8859-1" type="text/css"/>
	<style type="text/css">
	table.news td {border-top: solid thin black;}
	table.news tr {vertical-align: top;}
	table.news tr td.section {font-size: 20px; font-weight: bold;}
	table.news tr td.title {vertical-align: top; width: 30%; font-weight: bold;}
	table.news tr td.content {vertical-align: top; width: 70%;}
	</style>
	<title>Eclipse Project Kepler - New and Noteworthy</title>
	</head>
	<body>
	<div style="font-size: 20px; font-weight: bold;">Plug-in Development Environment</div>

	<!-- **************** START OF N&N TABLE **************** -->
	<table class="news" cellpadding="10" cellspacing="0">
	<tbody>

	<!-- ****************** APITools ******************** -->
	<tr>
	<td id="APITools" class="section" colspan="2"><h2>API Tools</h2></td>
	</tr>

	<tr id="ee-desc-feature">
	<td class="title">New API Tools EE descriptions feature</td>
	<td class="content">
	The API Tools Execution Environment descriptions are now supplied on the Eclipse update sites as a single
	installable feature. The feature includes the descriptions for all supported execution environments.

	<p><img src="images/eedescfeature.png" alt="New EE Desc feature on update sites"/></p>
	</td>
	</tr>

	<tr id="noreference-types">
	<td class="title">API Tools allows @noreference Javadoc tag on types</td>
	<td class="content">
	API Tools now allows the use of the <code>@noreference</code> Javadoc tag on types (classes, interfaces,
	annotations and enums).
	<p><img src="images/no-reference.png" alt="Type defining noreference Javadoc tag"/></p>
	<p>Placing this tag restricts the API so that any reference to that type or its members
	will be flagged as invalid API use.</p>
	<p><img src="images/using-no-reference.png" alt="Class trying to reference a type marked as noreference"/></p>
	<p>
	To mark a type in an API package as not being API, tag it as <code>@noreference</code>,
	<code>@noextend</code> and <code>@noinstantiate</code> (or <code>@noimplement</code>). This ensures that
	no client can access it via valid API and the type could later be removed.
	</p>
	</td>
	</tr>

	<tr id="api-tags-check-visibility">
	<td class="title">API Tools Javadoc tags check visibility</td>
	<td class="content">
	A member that is not publicly visible, such as a method or field marked private, is not part
	of API. Any API Tools Javadoc tags on it are invalid. Now, API Tools will also check if a
	member is not visible because of the visibility of an enclosing type. If the member is not visible,
	any tags on it will be considered invalid.
	<p><img src="images/api-parent-not-visible.png" alt="Javadoc tag flagged as invalid because member is not visible"/></p>
	<p>
	Tag validation is turned off by default. To turn it on for your API Tools enabled project, open
	<b>Project Properties > Plug-in Development > API Errors/Warnings</b>. Set
	<b>API Use > General > Unsupported use of API Javadoc tags</b> to <code>Warning</code> or <code>Error</code>.
	</p>
	</td>
	</tr>

	<tr id="support-pre-osgi-bundles">
	<td class="title">API Tools has limited support for pre-OSGi Eclipse plug-ins</td>
	<td class="content">
	Eclipse plug-ins created before 3.1 did not contain an OSGi bundle manifest. API Tools
	can now convert the pre-OSGi plug-ins to valid components in an API baseline. This allows
	analysis, use and freeze scans to process plug-ins that depend on pre-OSGi plug-ins instead
	of failing to resolve.
	<p><img src="images/use-scan.png" alt="Use scan launch configuration with pre-OSGi plug-ins"/></p>
	<p>
	An OSGi runtime is required to do the conversion. Tasks run using Eclipse AntRunner
	or the API Use Report external tools launch configuration can convert the plug-ins. Tasks
	run from the command line Ant runner will skip pre-OSGi plug-ins.
	</p>
	</td>
	</tr>

	<tr id="api-unresolved-bundles">
	<td class="title">API Tools Analysis and Freeze tasks can run with unresolved bundles</td>
	<td class="content">
	The API Tools <b>Analysis</b> and <b>API Freeze</b> Ant tasks will now process bundles
	with resolver errors such as missing dependencies. This means you can now get analysis results
	for an incomplete product.
	<p>
	The Ant tasks produce reports based on a reference baseline and a profile. Previously both
	the baseline and the profile had to describe complete products. Any bundle that had resolver
	errors due to missing dependencies would be skipped. Now these bundles will be processed.
	</p>
	<p>
	Resolver errors can affect the results, therefore a list of resolver errors is included in the XML output
	and warnings are added to the HTML report. To return to the old behavior of skipping
	unresolved bundles, you can set <code>processunresolvedbundles="false"</code> on your Ant task.
	</p>
	<p>
	<img src="images/unresolved-analysis.png" alt="Unresolved bundle in the analysis task"/>
	</p>
	</td>
	</tr>

	<tr id="api-use-filters">
	<td class="title">Problem filters apply to API Tools use scans</td>
	<td class="content">
	Problem filter files (.api_filter) can be used to filter problems reported by the API Tools analysis
	task and the workspace analysis builder. These filter files can now be applied to API Tools use scans.
	Reference problems that are filtered out of the analysis results can also be filtered from the results
	of use scans.
	<p>
	Filters are specified in the task using the same property as the analysis task. Set the <em>filters</em>
	attribute on the <em>apitooling.apiuse</em> task, specifying the root directory of API filter files. Each
	filter file must be in a folder with a filename matching the component name the filter file applies to.
	</p>
	</td>
	</tr>

	<tr id="missing-filters-on-tasks">
	<td class="title">API Tools tasks warn about missing include or exclude files</td>
	<td class="content">
	Many of the API Tools tasks, including Analysis, API Use, and API Freeze, provide <em>includelist</em> and
	<em>excludelist</em> attributes which can be used to limit the reported problems. Previously,
	if you set an include or exclude list, but the file wasn't found, the task would continue without warning
	about the incorrect filtering. Now a missing include or exclude list will result in the task failing with
	an explanation.
	<p>
	<img src="images/missing-include.png" alt="Example console output for missing include"/>
	</p>
	</td>
	</tr>

	<!-- ****************** Views and Editors ******************** -->
	<tr>
	<td id="ViewsAndEditors" class="section" colspan="2"><h2>Views and Editors</h2></td>
	</tr>

	<tr id="improved-feature-selection">
	<td class="title">Improved feature selection dialog</td>
	<td class="content">
	The feature selection dialog used in wizards and editors has been enhanced with better wildcard support
	and filtering options.

	<p><img src="images/featureselection.png" alt="Improved feature selection dialog"/></p>
	</td>
	</tr>

	<tr id="additional-type-info">
	<td class="title">Javadoc hover available in plug-in manifest editor</td>
	<td class="content">
	When editing the plugin.xml or manifest.mf files using the <b>Plug-in Manifest Editor</b>,
	opening content assist for type proposals will now display additional Javadoc information.
	<p>
	<img src="images/additional-type-info.png" alt="Additional info Javadoc hover for type proposals"/>
	</p>
	</td>
	</tr>

	<tr id="import-package">
	<td class="title">New import package quick fixes</td>
	<td class="content">
	New quick fixes are available when you have an unresolved type in a Java file. If the unresolved type
	can be found in a package exported by a plug-in, a quick fix will be available to add an import
	package entry to your plug-in manifest. There is also a quick fix to add the exporting plug-in to
	your manifest's require bundle header.
	<p>
	<img src="images/import-package.png" alt="Import package quick fix on an unresolved type"/>
	</p>
	<p>
	If a package providing the type is available but the package is not exported by its plug-in, a quick fix will
	offer to fix the providing plug-in's manifest. Only plug-ins in the workspace can be modified this
	way.
	</p>
	<p>
	<img src="images/export-package.png" alt="Export package quick fix on an unresolved type that is not exported"/>
	</p>
	</td>
	</tr>

	<tr id="bundles-in-category-editor">
	<td class="title">Bundles in the category editor</td>
	<td class="content">
	The category editor now supports putting individual bundles into categories.
	<p>
	The category editor creates a category.xml that can define categories that the contents of
	a p2 repository should be organized into. Previously only features could be specified as belonging
	to a category and be visible to users. Now individual bundles can be added to the category.xml.
	</p>
	<p>
	<img src="images/category-editor.png" alt="Category editor can include individual bundles"/>
	</p>
	</td>
	</tr>

	<tr id="plugin-image-view">
	<td class="title">Plug-in image browser view</td>
	<td class="content">
	A new view has been added to PDE. The <b>Plug-in Image Browser</b> view displays icons and other
	images from your target platform, running application or current workspace.
	<p>
	When an image is selected, additional information is displayed at the bottom of the view. The
	reference text can be used in plug-in extensions to refer to images in other bundles.
	</p>
	<p>
	<img src="images/plugin-image-view.png" alt="The plug-in image browser view"/>
	</p>
	</td>
	</tr>

	<!-- ****************** Misc ******************** -->
	<tr>
	<td id="Misc" class="section" colspan="2"><h2>Misc</h2></td>
	</tr>

	<tr id="default-launch-ee">
	<td class="title">Launch configurations choose default execution environment</td>
	<td class="content">
	New PDE launch configurations (Eclipse Application, JUnit Plug-in Test, OSGi Framework) will
	use a default execution environment to determine which Java runtime environment to launch with.
	The launch configuration can be changed to use a different execution environment or a specific
	JRE on the <b>Main</b> tab.
	<p>
	To find a valid execution environment, all known environments are checked against each bundle
	or plug-in that will be launched. Only an execution environment that is valid for all
	plug-ins and bundles will be selected. If no valid environment is found, a default JRE
	will be chosen as before.
	</p>
	<p>
	<img src="images/default-launch-ee.png" alt="Java runtime settings on the Main tab of PDE launch configurations"/>
	</p>
	<p>
	The JRE associated with the selected execution environment will be used to launch. To change
	which JRE is associated with an execution environment, use the <b>Preferences > Java > Installed JREs >
	Execution Environments</b> preference page.
	</p>
	</td>
	</tr>

	<tr id="pde-5-bree">
	<td class="title">PDE UI requires a 1.5 EE</td>
	<td class="content">
	The bundle required execution environment for the PDE UI bundles org.eclipse.pde.core and
	org.eclipse.pde.ui is now J2SE-1.5.
	</td>
	</tr>

	<tr id="plugin-classpath-contributors">
	<td class="title">New API to contribute to the classpath of plug-in projects</td>
	<td class="content">
	New API in PDE allows you to add additional classpath entries to a plug-in project. Contribute a
	<em>Plug-in Classpath Contributor</em> via the <em>org.eclipse.pde.core.pluginClasspathContributors</em>
	extension point. Whenever the PDE classpath is computed or a new plug-in dependency is added, your classpath
	contributor will be queried for additional entries.
	<p>
	If you are using Equinox Adapter hooks to load additional libraries at runtime you can use this API to add
	the correct libraries to the classpath at build time.
	</p>
	<p>
	<img src="images/classpath-contributor.png" alt="An example classpath contributor extension"/>
	</p>
	</td>
	</tr>

	<tr id="update-classpath-workspace">
	<td class="title">Updating the classpath requires a workspace lock</td>
	<td class="content">
	When a change is made to a plug-in that forces a classpath update, an update job is created that
	modifies the Plug-in Dependencies classpath container in the background. This job now acquires a workspace lock
	to prevent other operations such as builders from running on a stale classpath.
	<p>
	This behaviour can be enabled in 4.2.2 by setting the system property <em>pde.lockWorkspaceForClasspath</em> to
	true.
	</p>
	</td>
	</tr>

	<tr id="auto-start-all-plugins">
	<td class="title">Default start level settings apply to all plug-ins</td>
	<td class="content">
	When editing the <b>Plug-ins</b> tab of an <b>Eclipse Application</b> launch configuration, the <b>Default
	Start level</b> and <b>Default Auto-start</b> settings chosen at the top of the tab will be used when launching with
	all workspace and enabled target plug-ins. Previously this setting would only be used when launching a
	specific list of plug-ins.
	<p><img src="images/autostart-all-plugins.png" alt="All plug-ins selected on the tab"/></p>
	<p><img src="images/autostart-levels.png" alt="Different default start level settings"/></p>
	</td>
	</tr>

	<tr id="pde-run-remembers-selection">
	<td class="title">Running from PDE editors remembers previous launch</td>
	<td class="content">
	The PDE editors allow applications to be launched from the top toolbar of the <b>Manifest</b>, <b>Plug-in</b>
	and <b>Product</b> editors. By default PDE only provides one type of application to launch. However, if you have additional tooling
	installed such as RAP Tools, different application launches will be available in a drop down menu.
	<p><img src="images/launch-order.png" alt="Ordering of launches in editor"/></p>
	<p>
	This menu now remembers which application was launched most recently and puts it at the top of the list. The most
	recent choice will be launched if the run button is pressed. The order is saved between workbench
	restarts.
	</p>
	</td>
	</tr>

	<tr id="pde-junit-e4">
	<td class="title">JUnit plug-in tests can run on Eclipse platform 4 workbench</td>
	<td class="content">
	Applications that use the Eclipse Platform 4 workbench API can now
	use <b>JUnit Plug-in Test</b> launch configurations to test their plug-ins. Previously
	the tests would require the 3.x workbench API from the <code>org.eclipse.ui</code> bundle to
	hook into the workbench lifecycle.
	</td>
	</tr>

	<!-- **************** END OF N&N TABLE **************** -->
	</tbody>
	</table>

	<p align="center"><a href="eclipse-news-part3.html">Previous</a>     <font color="#808080">Next</font></p>

	</body>
	</html>