Plug-in Development Environment

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

Views and Editors
OSGi console An OSGi console is now available to interact with the running framework. Use the Open Console drop down action in the Console View to open a Host OSGi Console.

Open an OSGi console to interact with the running framework

You can then enter OSGi commands into the console to interact directly with the framework running the IDE.

XML error reporting in context help and table of contents editors The context help editor and table of contents editor now report XML errors.

TOC Editor

Spell checking in context help and table of contents editors

Spell checking is now available in the Table of Contents (TOC) and Context Help editors.

Incorrectly spelled works are underlined in red

Configurable problem severities for build.properties Severities for problems in build.properties can now be configured individually via the Preferences > Plug-in Development > Compilers preference page. Problem severities can also be configured at the project level via a project's Properties > Plug-in Development > Plug-in Manifest Compiler property page.

Severity Settings

Search repositories quickfix A new quickfix allows you to conveniently search a set of repositories for a missing imported package and have a bundle supplying the package added to your target platform.

Search Repositories Quickfix

API for plug-in project creation An API is now available to create and modify plug-in (bundle) projects. The API provides a description of a project's bundle related attributes and allows them to be modified declaratively. For example, a bundle's activator, required bundles, package exports and imports can be queried and defined. As well, the root of bundle (i.e. the folder containing META-INF/MANIFEST.MF) can be placed anywhere inside a project (rather than just the root project folder). The new API is available in the org.eclipse.pde.core.project package of the org.eclipse.pde.core bundle.
Launching
Feature based launch You can now manage the set of plug-ins launched in Eclipse Applications, JUnit Plug-in Tests, and OSGi Framework launch configurations by selecting a set of features.

Feature Based Launching

Features from both the workspace and the target can be included. Individual plug-ins can be added to the launch to include plug-ins that are not part of a feature. PDE will launch all the selected plug-ins as well as all required plug-ins.

Add individual plug-ins to a feature based launch

Features in the workspace are used over external features, however, this can be configured by un-checking 'Use features from workspace if available'. Bundles in the workspace are used over external bundles in the target platform. However, this can be configured by modifying the configuration's default bundle resolution policy, or can be configured per feature using the cell editors in the 'Plug-in Location' column.

Headless launching support Launching support for Eclipse Applications, JUnit Plug-in Tests, and OSGi Frameworks is provided by a new headless plug-in (org.eclipse.pde.launching). This allows applications without a user interface to leverage the launch support programmatically.
Console log By popular demand, -consoleLog is added to new launch configuration program arguments by default.

Default program arguments

Support software installation while running and debugging Launched Eclipse Applications can now support software installation operations. When the new option is checked (on the Configuration tab of Eclipse Applications), a p2 profile is generated when running or debugging. The profile initially contains all bundles in the target and can be modified by software installation operations. The profile is regenerated on each subsequent run or debug session, but is maintained across restart operations.

Configuration tab of Eclipse Application

Import and Export
Import from CVS The Plug-in Import wizard allows you to import projects from CVS corresponding to bundles in the target platform. This feature is available for bundles that define the Eclipse-SourceReferences header. On the first page of the import wizard select the Import As > Projects from a repository option.

Import from a repository

The second page allows you to choose from all bundles with source repository information. Select the bundles you want to import and press Next.

Select bundles to import

The last page of the wizard allows you to import the specific versions of the bundles used in the target platform or from HEAD. Pressing Finish will import the projects into your workspace.

Select Version

You can also import projects from the Plug-ins view. Use the Import As > Project from a Repository... action to import plug-ins from CVS.

Import plug-in projects from CVS

Export target content It's now possible to export the contents of your current target platform into a destination directory via the export active target definition wizard. In the list of export wizards (File -> Export...), you'll find the wizard available under Plug-in Development -> Target definition.

Export Active Target Wizard

Note: This will copy all features and plug-ins that are part of your currently set target platform to the destination directory.

Target Platform
Feature based target You can now manage the set of bundles in a target platform by selecting a set of features. Additionally, you can select from bundles that are not contained in any feature. On a target definition's Content tab select the Manage using Features radio button. This provides coarse grained management of bundles in a target. When a feature is selected, all bundles in that feature are added to the target.

Target Based Features

Add to target platform dialog The Add Artifact to Target Platform dialog (Ctrl+Shift+Alt+A) allows you to quickly search a set of repositories for dependencies (bundle, feature or package) to add to your current target platform.

Add Artifact to Target Platform Dialog

API Tooling
Compare with baseline now reports deprecations When performing Compare With > API Baseline..., deprecation changes are now reported. This allows you to quickly identify what has been deprecated between two releases of a project.

TOC Editor

API use reports

You can generate reports describing what API and internals are being used by other bundles. API use reports have been integrated as an external tool (Run > External Tools > External Tool Configurations...). For example, the following report settings are used to generate a report revealing which internal components of the debug platform are being consumed by JDT.

API use report settings

A report is run against a set of bundles which can be specified as an API baseline, a target definition or a directory of bundles. You can search for API and/or internal references and you can limit the report to specific bundles by using regular expressions. You must specify an output location (directory) for the report and whether to generate HTML.

Package exports in bundle manifests are used to determine package visibility. Any package exports with an x-internal or x-friends modifier will be considered internal. All other packages are considered API. The Patterns tab can be used to augment package visibility information by specifying regular expressions to identify packages, and whether those packages should be considered API or internal. For example, since TPTP specifies all packages as API, the following patterns could be used to identify its internal packages.

Specify package visibility using the patterns tab

Customize API use scan reports A new wizard helps you customize API use reports. From the Patterns tab of an API Use Report launch configuration (available via External Tools), press the Add button to open the wizard and create custom pattern filters.

API Pattern Wizard

An Archive Pattern allows specific jars within bundles to be omitted from the scan. A Package Pattern allows you to specify which packages should be considered API or non-API (override visibility definitions in bundle manifests). A Report Conversion Pattern allows specific references to be filtered from the final report. You can filter references from or to locations based on regular expressions.

Enhanced build.properties validation Redundant entries in source builds are now flagged with a warning by default.

Source folder validation

API use report filters You can now add filter patterns to API use reports to constrain what references are reported. This feature is available in UI and in API tooling Ant tasks. When you press Add on the Patterns tab a wizard allows you to craft a variety of patterns. An archive pattern is used to skip specific jars. A package pattern is used to define a package as API or internal (to override a bundle manifest). A report conversion pattern is used to skip specific references during report creation (by specifying a regular expression of reference origins to skip).

Create new patterns using the convenient wizard

For example, to use an archive pattern to filter references from specific archives within bundles, select Archive Pattern and press Next. The wizard allows you to easily craft an archive pattern.

Create a new archive pattern using the convenient wizard

When you press Finish the pattern appears in the Patterns table.

Archive pattern

API use report details You can now provide comments to accompany an API use report, which will show up in the reports as additional information along with the scan parameters for reference. This feature is available in the UI and in API tooling Ant tasks.

Scan description

The resulting report could look like the following.

Sample use scan details report header.

Build
Enhanced compiler error options for PDE build PDE/Build can now take advantage of new support from the JDT compiler to specify that certain warnings should instead be reported as errors.

Set the property javacErrors.<library> in your build.properties. Similar to the javacWarnings.<library> property, specify the warnings that should be reported as errors:

    	javacErrors.. = forbidden,discouraged,
    	javacErrors.library.jar = deprecation,nullDereference
    	
Synchronize project settings with PDE build To ensure PDE will export and build your project with the same settings as in the workspace there are new checks to synchronize project specific compiler and build path settings with build.properties. The following validations are performed and quick fixes are provided for any problems.
  • Compiler compliance, source and target levels match jre.compliance.profile, javacSource, and javacTarget properties (only required when compiler settings do not match default settings for a bundle's required execution environment).
  • Folders in source.<library> exist, are source folders on the Java build path, and are not duplicated.
  • Folders in output.<library> exist, are output folders or class file folders on the Java build path, and are not duplicated.
  • Each output.<library> entry contains all output locations of its corresponding source folders on the Java build path.
  • Source folders targeted to different libraries do not share the same output location.
  • Source folders are not included in src.includes entries (they are included by default).
  • Additionally, a check can be performed to ensure an output.<library> exists for each source.<library> entry. By default, this problem is ignored but can be turned on via Preferences > Plug-in Development > Compilers (or project specific Properties > Plug-in Development > Plug-in Manifest Compiler). This option is useful when using the PDE option to export existing class files from the workspace.

Build.properties validation

Synchronize project settings with PDE build It's easier to synchronize your project specific compiler settings and file encoding settings with PDE build. Two new options appear in the Build section of the Preferences > Plug-in Development > Compilers preference page. By default the new options are set to Ignore.

Build validation settings

When set to Warning or Error problem markers will appear when your project settings are not reflected in build.properties. Quick fixes are available to help you synchronize the settings.

Warnings

A new javacProjectSettings property is supported in build.properties. The value can be a project relative path to a preference settings file of compiler options supported by the JDT compiler, or it can simply by true to indicate the default preference file should be used (.settings/org.eclipse.jdt.core.prefs).

Plug-in specific compiler arguments A bundle can now specify custom compiler arguments to be used in export or releng builds by setting compilerArgs in its build.properties file..

These arguments will be specified in addition to whatever general compiler arguments are specified by the releng setup.

Custom compiler adapters A bundle can now specify a custom ant compiler adapter to be used during export or releng builds. This allows for compiling non-java sources such as AspectJ or Groovy provided a suitable adapter is available.

Set compilerAdapter in the bundle's build.properties file. As well, set sourceFileExtensions to a list of file extensions which should be treated as source and automatically copied to generated source bundles.

Improved error reporting from PDE build A new prereqErrors.log file is generated by PDE build. The file helps locate bundles lowest on the stack with compilation errors. An entry is added for each bundle with build errors describing any prerequisite bundles that contained compile errors. Entries are added in the order bundles are compiled. For example:

org.eclipse.debug.ui_3.6.0.201004141459: the following prerequisites contain compile errors
    org.eclipse.debug.core_3.6.0.201004141459

Previous     Next