Plug-in Development Environment

API Tools

New API Tools EE descriptions feature 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.

New EE Desc feature on update sites

API Tools allows @noreference Javadoc tag on types API Tools now allows the use of the @noreference Javadoc tag on types (classes, interfaces, annotations and enums).

Type defining noreference Javadoc tag

Placing this tag restricts the API so that any reference to that type or its members will be flagged as invalid API use.

Class trying to reference a type marked as noreference

To mark a type in an API package as not being API, tag it as @noreference, @noextend and @noinstantiate (or @noimplement). This ensures that no client can access it via valid API and the type could later be removed.

API Tools Javadoc tags check visibility 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.

Javadoc tag flagged as invalid because member is not visible

Tag validation is turned off by default. To turn it on for your API Tools enabled project, open Project Properties > Plug-in Development > API Errors/Warnings. Set API Use > General > Unsupported use of API Javadoc tags to Warning or Error.

API Tools has limited support for pre-OSGi Eclipse plug-ins 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.

Use scan launch configuration with pre-OSGi plug-ins

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.

API Tools Analysis and Freeze tasks can run with unresolved bundles The API Tools Analysis and API Freeze 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.

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.

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 processunresolvedbundles="false" on your Ant task.

Unresolved bundle in the analysis task

Problem filters apply to API Tools use scans 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.

Filters are specified in the task using the same property as the analysis task. Set the filters attribute on the apitooling.apiuse 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.

API Tools tasks warn about missing include or exclude files Many of the API Tools tasks, including Analysis, API Use, and API Freeze, provide includelist and excludelist 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.

Example console output for missing include

Views and Editors

Improved feature selection dialog The feature selection dialog used in wizards and editors has been enhanced with better wildcard support and filtering options.

Improved feature selection dialog

Javadoc hover available in plug-in manifest editor When editing the plugin.xml or files using the Plug-in Manifest Editor, opening content assist for type proposals will now display additional Javadoc information.

Additional info Javadoc hover for type proposals

New import package quick fixes 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.

Import package quick fix on an unresolved type

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.

Export package quick fix on an unresolved type that is not exported

Bundles in the category editor The category editor now supports putting individual bundles into categories.

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.

Category editor can include individual bundles

Plug-in image browser view A new view has been added to PDE. The Plug-in Image Browser view displays icons and other images from your target platform, running application or current workspace.

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.

The plug-in image browser view


Launch configurations choose default execution environment 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 Main tab.

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.

Java runtime settings on the Main tab of PDE launch configurations

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 Preferences > Java > Installed JREs > Execution Environments preference page.

PDE UI requires a 1.5 EE The bundle required execution environment for the PDE UI bundles org.eclipse.pde.core and org.eclipse.pde.ui is now J2SE-1.5.
New API to contribute to the classpath of plug-in projects New API in PDE allows you to add additional classpath entries to a plug-in project. Contribute a Plug-in Classpath Contributor via the org.eclipse.pde.core.pluginClasspathContributors 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.

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.

An example classpath contributor extension

Updating the classpath requires a workspace lock 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.

This behaviour can be enabled in 4.2.2 by setting the system property pde.lockWorkspaceForClasspath to true.

Default start level settings apply to all plug-ins When editing the Plug-ins tab of an Eclipse Application launch configuration, the Default Start level and Default Auto-start 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.

All plug-ins selected on the tab

Different default start level settings

Running from PDE editors remembers previous launch The PDE editors allow applications to be launched from the top toolbar of the Manifest, Plug-in and Product 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.

Ordering of launches in editor

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.

JUnit plug-in tests can run on Eclipse platform 4 workbench Applications that use the Eclipse Platform 4 workbench API can now use JUnit Plug-in Test launch configurations to test their plug-ins. Previously the tests would require the 3.x workbench API from the org.eclipse.ui bundle to hook into the workbench lifecycle.

Previous     Next