Plug-in Development Environment
Views and Editors
Declarative services editor PDE has added declarative services tooling to help author service component definitions.

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

Jump to Console from stack trace The error log view has been enhanced to allow posting stack trace 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
Install into running platform

It's simple to run and test your latest code by exporting and install plug-ins and features directly into the running workbench. Choose Install into host when exporting and specify a path in the local file system where exported artifacts can be stored (repository). You will be prompted to restart your workspace after export and install is complete.

Export Wizard

Patched plug-ins will appear in the installed software list and can also be uninstalled.

Installation Details Dialog

Source bundles, binary cycles, and workspace class files

Export options have been enhanced:

  • Generate 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 features, plug-ins, and products with binary cycles. Binary cycles are cycles that exist in your target platform, not your workspace. This option is on by default.
  • 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 export.

Export Wizard Options Tab

Publish feature categories

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

API Tooling
Compatibility options

API compatibility options have been reorganized and descriptions have been improved. The number of options has been reduced by combining related problems. For example, problems related to type parameters are now in their own group rather than being listed separately in the settings for classes, interfaces, and methods.

As well, you can 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 API Compatibility tab). When this preference is enabled you must use API problem filters to selectively permit incompatible API changes.

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).

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.3, but the only JRE installed in the workspace for building is J2SE 1.5, it is possible to access methods that exist in J2SE 1.5, but not in J2SE 1.3. 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 Use tab of 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.

Illegal access warning

Stale 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

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.

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

When building products using p2.gathering=true, 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 (needs to be on one line) 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 and target definitions

The target platform preference page (Preferences > Plug-in Development > Target Platform) has been redesigned. The page allows the user to select the active target platform from all target definitions in the workspace. Target definitions can be created and edited from this page using a wizard or with the target definition editor. You can quickly switch between targets using the checkboxes. Targets can be composed of plug-ins originating from installations, directories, features, and software sites. See target definition concepts for more details on crafting targets.

Target platform preference page

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

Previous     Next