Plug-in Development Environment

Target definitions

You can now define a target in a .target file (File > New > Other... > Plug-in Development > Target Definition).

The .target file defines all aspects of a target including name, location, content (in terms of plug-ins, features, or both) and JRE.

More notably, you can specify and manage multiple plug-in sites in the target without the need for .link files.

The Plug-in Development > Target Platform preference page lets you browse, preview and apply existing target definitions.

target editor

Contributing targets

Targets can be contributed to an Eclipse product via the org.eclipse.pde.core.targets extension point.

The Eclipse SDK comes with two RCP-centric org.eclipse.pde.core.targets extensions, allowing you to easily switch the target platform back and forth between the SDK and the RCP subset.

predefined targets

Hierarchical view of plug-ins

The plug-ins on the Plug-in Development > Target Platform preference page can now be grouped by sites. This hierarchical view makes the management of large and distributed targets much easier.

target hierarchy

Plug-ins for any OSGi framework

The New Plug-in Project creation wizard (File > New > Project...> Plug-in Project) now provides the option to create plug-ins that can run with any OSGi framework.  A Hello OSGi template is also provided.


Equinox OSGi framework launcher

A new launcher is now available to run and debug bundles with the Equinox OSGi framework. You will be able to set the start level of your bundles and customize program and VM arguments to test your bundles under different conditions.

An Equinox OSGi framework launch configuration can be created in the Launch Configuration dialog (Run > Run... from the top level menu).

equinox launcher

Plug-in manifest files participate in refactoring

When you move or rename a Java type or package in your plug-in, PDE now automatically updates all references to these types and packages in the manifest files of the affected plug-ins.

NLS wizard for plug-in manifest files

PDE now provides a wizard to extract translatable strings from plug-in manifest files and store them in a properties files for multi-language support.

The wizard is available via PDE Tools > Externalize Strings... in the context menu of plug-in projects and their manifest files.

nls wizard

Organize plug-in manifest files

The Organize Manifests wizard is an appointment stop prior to shipping a plug-in.  It removes unused dependencies and property keys, and manages the exported packages ensuring they are marked with the right visibility.

This function can be invoked via PDE Tools > Organize Manifests... from the context menu of plug-in projects and MANIFEST.MF files.

organize manifests wizard

New processing instruction in plugin.xml files

Plug-in manifest files generated by PDE now contain a new processing instruction indicating version 3.2, instead of 3.0. This new processing instruction is required if a plug-in is to take advantage of the new runtime support where a plug-in can contribute extension points and extensions to a namespace other than its own.

In the example below, the org.eclipse.pde.core plug-in contributes an extension to the org.eclipse.pde namespace

processing instruction

Note that there is no need to migrate an existing plug-in to use the new processing instruction unless you want to use the new namespace support in that plug-in.

Bundle execution environment

A bundle execution environment specifies the minimum level of JRE required for the plug-in to run. If the JRE used to run Eclipse does not meet the requirement, the plug-in will not run.

If you declare J2SE-1.4 as your plug-in's bundle execution environment, for example, your plug-in will run with a JRE version >= 1.4.

If the plug-in can run in execution environments that are not proper subsets of each other (e.g J2SE-1.4 and CDC-1.1/Foundation-1.1), then all such bundle execution environments should be listed.

The Execution Environments section is on the Overview page of the plug-in manifest editor.

During a plug-in export, the plug-in code is compiled against the JRE associated with the first execution environment listed in the MANIFEST.MF.  Refer to the Java > Installed JREs > Execution Environments preference page for a list of OSGi execution environments and the list of installed JREs that are compatible with each.

execution environment

Automated management of dependencies

PDE now provides a new flexible workflow that allows you to code your plug-in first, and then have your code analyzed, and the list of plug-in dependencies automatically generated for you by PDE after.

The Automated Management of Dependencies section on the Dependencies page of the plug-in manifest editor lets you specify a list of plug-ins that you wish to augment your development build path (and hence your content assist scope) with.

These dependencies do not get added to the MANIFEST.MF immediately, but you can start coding right away as if they were.

At any time, you can tell PDE to analyze your code and generate the correct dependencies in your MANIFEST.MF via either the Require-Bundle or Import-Package headers.

dependency management

Structural compare and syntax highlighting for files

When comparing two versions of a bundle MANIFEST.MF file, the new structure compare viewer will let you easily see what headers have been added, removed or modified.

manifest structure compare

Syntax highlighting has also been added to the MANIFEST.MF source page. Colors and fonts preferences can be set on the Plug-in Development > Editors preference page.

Validate files

PDE now validates files to flag potential problems that would prevent your plug-in from being exported properly. validation

The severity level for problems in files can be set on the Plug-in Development > Compilers > Plug-ins preference page.

notification severity

Quick fixes for plug-in manifest files

Quick fixes are now available for many types of problems in MANIFEST.MF, plugin.xml and files, including:
  • unresolved type references
  • externalizing attributes and elements
  • replacement of deprecated attributes and directives


Automatic Javadoc attachment

PDE now automates the task of attaching Javadoc to libraries found on your plug-in's build path.

javadoc attachment

Refer to the org.eclipse.pde.core.javadoc extension point documentation for full details.

New extension point schema editor

The extension point schema editor has been redesigned. New features include:
  • better visualization of the schema
  • simpler editing of attributes
  • drag and drop
  • inclusion of other schemas

schema editor

Headless RCP application template

The Eclipse runtime is a rich Java component model ideal for running headless (non-UI) applications.

The New Plug-in Project creation wizard (File > New > Project...> Plug-in Project) now supports a workflow to create headless RCP applications, complete with a Hello World template.

headles rcp

Form validation in product editor

The product editor now reports warnings and errors in the title area of each page. Problems reported include invalid paths and the wrong size and depth of an image.

form validation

Integrated progress monitor in product splash screen

If you like the integrated progress bar in the Eclipse splash screen, you can easily do the same for your product splash screen.

The Branding page of PDE product editor provides support to add and customize an integrated progress bar.

progress bar and message branding

Platform-specific launcher arguments for cross-platform product export

In the product editor, it is now possible to specify platform-specific program and VM arguments to launch a product with. This allows the creation of platform-specific <launcher>.ini files in a single cross-platform export operation.

platform specific launcher arguments

Add a Welcome page to your product

A welcome page is your opportunity to provide a pleasant initial user experience to your product.

The Branding page of the product configuration editor (File > New > Other...> Product Configuration) now has a Welcome Page section, which will help you create a template welcome page for your product.

welcome branding

Sharable and portable PDE launch configurations

The PDE launch configurations (Eclipse Application and Plug-in JUnit) now support variable substitutions. Careful use of variables allows the saved form of the launch configuration to be portable across operating systems and sharable across teams.

Templates for launching arguments

You can now specify a template for program and VM arguments, which will be used to initialize default arguments on new PDE launch configurations.

launching templates

Enhanced and automatic plug-in validation prior to launching

The Validate Plug-in Set functionality, available on the Plug-ins tab of all PDE launchers, analyzes the list of selected plug-ins to find lurking launching startup problems. 

This function has now been enhanced to forecast more types of unsatisfied constraints that would prevent your plug-in from running.

You can also opt to have this validation done automatically prior to every launch.

automatic plug-in validation

New source lookup for debugging Eclipse applications

When debugging Eclipse applications, PDE now uses a custom source lookup mechanism that is tied to the OSGi class loader. This is both faster and more accurate than the standard linear Java source lookup.

The Source tab has been removed from the Eclipse/Equinox/Plug-in JUnit launch configurations as it is no longer needed.

Plug-in level custom Ant targets

The generated build.xml for a plug-in now supports custom targets at the plug-in level. Set the property "customBuildCallbacks" in a plug-in's file to point at an Ant script and pre and/or post ant calls will be generated for the following targets: build.jars, build.sources, the compilation target (eq: @dot),, gather.sources, gather.logs, and clean. In many cases these custom callbacks can be used instead of having an entirely custom build.xml. A template customBuildCallbacks.xml is provided in

Building products

PDE Build now supports building products from a .product file in a headless automated build. A feature will be automatically generated based on the contents of the product file.

Multiple repository support

The PDE Build generation of fetch scripts for headless builds is now extensible. Extenders may contribute support for fetching elements from additional repositories through the extension point. PDE Build provides the standard extension for fetching files from CVS.

Previous     Next