What's New in 3.5 (PDE)

Here are descriptions of some of the more interesting or significant changes made to the Plug-in Development Environment (PDE) for the 3.5 release of Eclipse, grouped into:

Views and Editors

Declarative services editor PDE has added declarative services tooling to help author service component definitions.

Declarative Services Editor

Improved declarative services tooling Tooling for OSGi declarative services has been improved:
  • Improved and more intuitive icons and overlays
  • Enhanced validation and error reporting
  • Source editing and code completion enhancements

Declarative Services Editor

DS Tooling enhancements

The OSGi Declarative Services (DS) tooling has been enhanced to support the latest version of the DS specification. Specifically, a new modified attribute has been added to the component element.

A new template based on a simple dictionary service has been added to showcase Declarative Services tooling.

DS Template

Declarative services tooling

The declarative services tooling now supports the latest OSGi declarative services specification (1.1) update.

Declarative Services Tooling

Jump to Console from stacktrace The error log view has been enhanced to allow posting stacktrace dumps to the Console view from log messages.

Jump to Console

Versioning options To help developers follow versioning best practices, PDE has expanded its compiler options to include version constraint checks on imported packages, exported packages and required bundle statements.

Preferences > Plug-in Development > Compilers

Properties editor for .options

The standard properties file editor is now used for .options files in the workspace.

Property file editor

Product editor enhancements The product editor has been enhanced to support bundle start levels and product license information.
Product definition enhancements

You can now initialize product definitions from OSGi launch configurations.

NL fragment generation

A new wizard (PDE Tools->Internationalize...) supports the generation of NL fragments for plug-ins in the workspace. A project is generated for each selected plug-in containing skeleton properties files for each selected locale. The generated properties files contain the keys from each of the associated plug-in's properties files.

Wizard to generate NL fragments

Plug-in Spy and menus

View information about menus by invoking Plug-in Spy in menu introspection mode (Alt+Shift+F2) and selecting a menu item.

Menu Spy

Plug-in Registry view enhancements The Plug-in Registry view now supports browsing for OSGi services.

Browse for OSGi services using the registry view

Start levels Eclipse Application launch configurations now support start levels and auto-start settings. You can specify default start levels and auto-start settings for all plug-ins in the configuration, and provide specific settings for others by selecting the plug-in in the list.

Use the Plug-ins tab to specify start levels

JUnit plug-in tests in non-UI thread You can now launch JUnit Plug-in tests in a non-UI thread. A check box has been added to the Test tab to specify whether tests should run in the UI thread.

Check box for non-UI thread

Fragments in the Plug-in Registry view

The Plug-in Registry view now includes fragments. Simply expand a plug-in, and expand the Fragments element in the tree to see all available fragments of that plug-in.

Fragments

Export

Single-click export and install into running platform

PDE has enhanced bundle and feature export to install the resulting exported bundles/feature into the currently running workbench. This makes it simpler to run and test your latest code. Choose "Install into current platform" when exporting and specify a location where p2 metadata can be created. You will be prompted to restart your workspace after export and install is complete.

Export Wizard

The patched bundles will appear in the platform's installed software list, and can also be uninstalled.

Installation Information Dialog

 

Exporting with binary cycles PDE now supports exporting features, plug-ins and product with binary cycles. Binary cycles are cycles that exist in your target platform, not your workspace. This option can be toggled in the various PDE export wizards and is enabled by default.

Export Wizard Options Tab

Export plug-ins using class files from the workspace

Plug-in export now allows you to export existing class files from the workspace. When this option is checked, PDE will re-use existing class files in the workspace rather than compiling class files from source during the export.

Export existing class files option

Publish feature categories on export

The new Category Definition editor can be used to assign categories to features when exporting. The category names and descriptions will then appear in software selection dialogs. First, create a category definition file via File > New > Other... and select Plug-in Development > Category Definition. Define categories with symbolic identifiers, names, and descriptions, and then add features to each category.

Category Definition editor

When exporting your feature, specify the category file to apply when exporting via the Options tab.

Specify category file on export

The categories can then be seen when browsing the repository from the Install Software dialog.

Install new software dialog displays exported categories

Keypass support

The JAR signing support in PDE has been expanded to include support for keypasses.

Keypass support

Export source bundles

Plug-in export now supports the creation of source bundles. Select the Export source option and choose Generate source bundles from the drop down menu. A source bundle will be exported for each plug-in being exported.

Export source bundles option

API Tooling

API compatibility options

API compatibility options have been simplified. The number of options has been reduced, options have been re-grouped, and descriptions have been improved. For example, compatibility options related to type parameters are now in their own group rather being duplicated in the settings for classes, interfaces, methods, and so on.

A large regression test suite (with over 1600 tests) has been developed to validate API use, compatibility, and version management scenarios.

Preferences > Plug-in Development > API Errors/Warnings

@noextend restriction supported on interfaces

API tooling now supports two restrictions on interfaces: @noimplement and @noextend. This allows an interface to be extended when it is not intended to be implemented directly. For example, a client may be permitted to subclass an existing implementation of a @noimplement interface and extend the base interface with extra function.

Component owners should decide where to add @noextend tags on existing interfaces, as this was previously implicit. To maintain the API contracts specified in 3.4, @noextend tags can be added to all interfaces specified as @noimplement. In some cases the @noextend restriction can be omitted, as clients that extend and implement a @noimplement interface will still be flagged with errors. However, if you would like to reserve the right to add constants to an API interface in the future, you must add the @noextend tag. This is because adding a field to an interface is binary incompatible if clients can extend or implement an interface (see Evolving API Interfaces).

Selective API breakage

You can now be alerted to breaking API changes even if you have incremented the major version of your plug-in. The first time you change a plug-in's API in an incompatible way, problems inform you to increment the major version of your plug-in. Once you increment the major version of your plug-in, API tooling allows additional breaking API changes without warning. Use the new preference Report API breakage even if authorized by major version increment to enable this feature (on the Plug-in Development > API Errors/Warnings preference page, on the top of the API Compatibility tab). When this preference is enabled you must use API problem filters to selectively permit incompatible API changes.

Preference to report API breakage regardless of plug-in version numbers

Execution environment validation

API tooling now warns you when you accesses code in a system library that is not part of a plug-in's required execution environment. For example, if your plug-in's target environment is J2SE-1.3, but you are developing against a J2SE-1.5 JRE, it can be easy to unintentionally reference types and methods that only exist in J2SE-1.4 or J2SE-1.5. Such references are now flagged with problems. You can adjust the severity of this problem via the Invalid references in system libraries option on the API Use tab of the Plug-in Development > API Errors/Warnings preference page.

Illegal access warning

System library validation API tools can now analyze use of system libraries and create problems when code accesses members that may not be present at runtime. For example, when a plug-in specifies a required execution environment of J2SE 1.4, but the only JRE installed in the workspace for building is Java SE 6, it is possible to access methods that exist in Java SE 6, but not in J2SE 1.4. In order for the validation to work, you must install relevant execution environment descriptions from an update site.

API Errors/Warnings preference page

The API Errors/Warnings preference page displays installed execution environments. Use the "install them now" hyperlink to install additional environments via the software updates dialog.

Stale API problem filters

API tooling creates warnings for problem filters that are no longer needed. API problem filters often become stale because they are used to filter known incompatibilities between two specific releases. A quick fix is available to remove stale filters.

Quick fix to remove stale filters

API tooling Ant tasks

Ant tasks to perform API analysis and generate simple HTML reports are now available. These are the same Ant tasks used in the Eclipse SDK build. Documentation for each task is available in the Reference section of the Plug-in Development Environment Guide.

Ant task documentation

Compare APIs

You can now view API changes relative to an API baseline. Select a project or package in the Package Explorer and choose Compare With > API Baseline. Specify the API baseline you wish to compare against and press OK. The API Tooling view will summarize the API changes.

API Tooling view

Build

Sort plug-ins across feature boundaries

PDE/Build determines compilation order by sorting plug-ins according to their dependencies. Previously, this sorting was only done within a single feature and features were compiled depth first in the order they were included.

Set the property:
flattenDependencies=true
in your build's configuration, and PDE/Build will instead sort plug-ins across feature boundaries. This allows you to structure your features according to the best logical groupings without restrictions imposed by compilation requirements.
Parallel compilation

If plug-ins are sorted across feature boundaries (see above), PDE/Build can also group plug-ins allowing for parallel compilation.

Set the property:
parallelCompilation=true
in your build's configuration, and PDE/Build will group plug-ins for parallel compilation using Ant's <parallel> task. Setting the properties parallelThreadCount and parallelThreadsPerProcessor will control the corresponding attributes on the parallel task.
Build integration with p2 PDE/Build has updated integration with p2. It is now able to publish metadata directly from your source instead of generating it based on binary jars. For an existing feature or product build, set the property:
           p2.gathering = true
     

Setting this property will use the p2 publisher to gather up your bundle and publish it into a build specific repository.

For product builds, this will automatically perform a director install to create the final product archives. If you also set the p2.metadata.repo and p2.artifact.repo properties then build will mirror the resulting product metadata into those repositories.

For Feature builds, this will create a p2 repository for the final archive. This also has the effect of setting groupConfigurations=true and outputUpdateJars=true.

Feature rootfile artifacts When publishing metadata directly from source using the p2.gathering=true property, root files contributed by features will be published into the artifact repository and associated metadata will be created. The result is that installing your feature will also cause the feature's root files to be installed.
Qualifier replacement on .product files

PDE/Build will now replace the ".qualifier" on the version specified in a .product file used in a product build. Set the property p2.product.qualifier to be the qualifier you wish to use.

If no value is specified, the default will be either the value of forceContextQualifier or the default timestamp.

Fetch artifacts for your build using p2 A new extension has been added to PDE/Build that enables users to fetch artifacts from p2 repositories. You can now add an entry to your map file for build input and PDE/Build will retrieve the artifact and include it in the build.

The map file entry needs to include the id and version of the installable unit (IU), and the URI of the repository where the IU can be found. The metadata and artifact repositories are assumed to be co-located. An example is:

plugin@my.bundle.id,1.0.0=p2IU,id=my.bundle.id,version=1.0.0,repository=http:/example.com/repo

p2 repositories as a target for PDE Build

You can now specify a location that contains local p2 repositories in nested folders or zip files. The build will automatically transform the repositories into a form that PDE/Build can compile against.

There is a new processRepos phase in the main build script with corresponding pre and post targets in the customTargets.xml file.

You must set these properties in the build.properties for your builder. The repoBaseLocation is the location of the folder containing the local p2 repositories. The transformedRepoLocation is the location where the transformed artifacts will be placed after being processed.

repoBaseLocation=${base}/repos
transformedRepoLocation=${base}/transformedRepos

Target Platform

Target platform preference page A new preference page supports managing and editing of multiple target platforms: Plug-in Development > Target Platform (Experimental). The page displays all targets defined in the workspace. You can change the target platform used to build workspace plug-ins by checking it in the table.

Experimental Target Platform preference page

A wizard allows you to add and edit target platform definitions. You can seed a target platform from existing templates (for example, an RCP application), default settings, current target platform settings, or start from scratch. Target definitions created from the preference page are stored locally in your workspace metadata.

Wizard used to create a new target definition

The content page is used to modify the name, description, plug-ins, and environment settings associated with a target.

Wizard used to edit target definition

You can add plug-ins to a target definition from various sources: a directory, an installation (for example, an Eclipse SDK), a feature, or an update site.

Add plug-ins dialog

You can select specific plug-ins to include from each source (for example, a directory), by pressing Edit.... You can choose to include plug-ins by name and/or version. When a version is not specified the plug-in with the highest version identifier is used.

Plug-in selection dialog

This new page will replace the old preference page in future milestones and for the Galileo release.

Target platform

There is a new target platform preference page (Preferences > Plug-in Development > Target Platform). The page displays all target definitions in the workspace and sets the active target platform for the workspace. Target definitions can be created and edited from this page. You can quickly switch between targets by selecting the desired target and pressing the "Set Active" button.

Target platform preference page

Software site target provisioner

You can now create and share a target definition composed of software from software sites. For example, you can create a target definition composed of the Eclipse SDK from one site, and EMF from another site. You can use the target definition wizard or target definition editor to compose a target definition.

From the Preferences > Plug-in Development > Target Platform preference page, select Add... to create a new target definition. On the first wizard page, select "Nothing: Start with an empty target definition", and press Next. You can give the target a useful name, like "EMF Example". On the Locations tab, press Add... and select Software Site.

Selection Dialog

Press Next and use the Add Content page to select the software you want to add to your target. Specify a software site, check the software you want to add, and press Finish. Required content will be downloaded to a local repository, and the target will be populated with the associated bundles/plug-ins, when available locally.

Software Selection Dialog

You can then add EMF from the Galileo site. The Locations tab displays the sites and software in your target definition.

Software sites are shown in the Locations tab

The Content tab displays the associated plug-ins/bundles downloaded from the software sites. Plug-ins can be grouped by location (site) and local file system paths. As well, source bundles can be filtered from the view.

Plug-ins/bunldes are displayed in the Content tab

Target editor enhancements The target editor has been enhanced to support new features in target definitions. Targets now support installation-based locations in addition to directories and features. As well, the editor support retrieval of plug-ins from update sites. The wizards used to add content to a target definition are the same as described in the new target platform preference page (above).

Target Definition Editor

To support new features, the underlying target file format has been enhanced. The new editor continues to read old target files, but only writes files in the new format.

Target platform state

The new Target Platform State view displays all the bundles used to build, run and debug plug-ins with. The state is built from the active target definition.

Target Platform State view