Skip to main content

Plug-in Development Environment

Dialogs, Wizards and Views

Target Platform preferences The Preferences > Plug-in Development > Target Platform preference page now allows to change the height balance between 'Target definitions' and 'Locations' areas.


'Source' tab for Product and Category Editor The Product Editor and Category Editor now have a 'Source' tab to enable direct access to their manifests.

API Tools

Removing API restriction results in API error Removing PDE API tools restriction such as @noextend, @noimplement and @noinstantiate now results in an incompatible bundle version API tool error, since clients of this code can access more APIs after the removal.

A quick fix for this error is available, and it increases the minor version to reflect the code changes.

Run API analysis as application To ease automation without Ant, the API Tools analysis can be performed using a regular Eclipse application named

It can receive the following parameters:

  • -project </path/to/project> configures which project should be analyzed. It has to be a valid Plug-in project containing a .project file.
  • -dependencyList </path/to/a/dependencyList.txt> configures the target platform for the analysis. This file will be parsed, using new lines and colon (:) as separator and all tokens that match a path on the filesystem will be added to the Target Platform.
  • -baseline <default|/path/to/> specifies the baseline to use for comparison. If omitted or default, it is the current running platform. If a path to a .target file is specified, it will resolve the target definition and use the included bundles as baseline.
  • -failOnError If present, the application will return an error (non-0) in case of API errors.

The API analysis uses the project settings, but forces the incompatible api component version report major without breaking change and incompatible api component version report minor without api change rules breakage to be reported as errors.

Example of invocation can look like:

./eclipse -project /home/mistria/sandbox/org.eclipse.e4.ui.css.core -dependencyList /home/mistria/sandbox/org.eclipse.e4.ui.css.core/dependencies.txt -failOnError

Additionally to the potential non-0 result, example of output can look like:

1 API ERRORS * Marker [on: /org.eclipse.e4.ui.css.core/META-INF/MANIFEST.MF, id: 80, type:, attributes: [apiMarkerID: 4, charEnd: 228, charStart: 210, description: , lineNumber: 7, message: The minor version should be the same for version 0.11.400, since no new APIs have been added since version 0.12.700, messagearguments: 0.11.400#0.12.700, problemid: 926941240, severity: 2, sourceId: API Tools, version: 0.12.700.qualifier], created: 5/16/19, 5:36 PM] 1 API warnings * Marker [on: /org.eclipse.e4.ui.css.core, id: 81, type:, attributes: [apiMarkerID: 3, charEnd: -1, charStart: -1, lineNumber: 0, message: Execution environment references were not checked for 'org.eclipse.e4.ui.css.core' because no environment descriptions are installed. , messagearguments: org.eclipse.e4.ui.css.core, problemid: 665845798, severity: 1, sourceId: API Tools], created: 5/16/19, 5:36 PM]

Here is an example of how this could be used in Tycho to trigger API checks in a Tycho build, in pom.xml

								<!-- need to set workspace to a dir that's not a child of the project --> 
								<!-- This will constitute the default baseline -->

Previous Up Next

Back to the top