|Declarative services editor||PDE has added declarative services tooling to help author service component definitions.
|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.
|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.
|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.
|Properties editor for .options||
The standard properties file editor is now used for
|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.
|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.
|Plug-in Registry view enhancements||The Plug-in Registry view now supports
browsing for OSGi services.
|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.
|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.
|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.
|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.
Patched plug-ins will appear in the installed software list and can also be uninstalled.
|Source bundles, binary cycles, and workspace class files||
Export options have been enhanced:
|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.
When exporting your feature, specify the category file to apply when exporting via the Options tab.
The categories can then be seen when browsing the repository from the Install Software dialog.
The JAR signing support in PDE has been expanded to include support for keypasses.
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.
|@noextend restriction supported on interfaces||
API tooling now supports two restrictions on interfaces:
Component owners should decide where to add
|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.
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.
|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.
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.
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.
|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:
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.
If plug-ins are sorted across feature boundaries (see above), PDE/Build can also group plug-ins allowing for parallel compilation.Set the property:
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:
|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.
|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 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).
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.