Eclipse 3.5 - New and Noteworthy

Plug-in Development Environment

Views and Editors
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 `.options` files in the workspace.
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.
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. 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: 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.
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.
Keypass support	The JAR signing support in PDE has been expanded to include support for keypasses.
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.
@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. 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	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.
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 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.

Previous Next