Plug-in Development Environment

Views and editors

Properties in product editor The product editor now has support to view, add and edit configuration properties. The properties will be added to config.ini files generated using the product configuration.

Product Properties
Share licenses between features Many Eclipse features use the same license. For example, all features in the Eclipse SDK use the Eclipse Foundation Software User Agreement. Using the new shared license facility allows multiple features to reference license text and files from a single location. This makes updating licenses across multiple features easier and less error prone.

To make use of the shared license facility, simply open your feature.xml file in the feature editor. Select the Information Tab and then the License Agreement section. Selecting the Shared license radio button will allow you to specify the feature and version that contains your license text and optional license files.

Feature Editor With Shared License

When your feature is built it's license text will be taken from the feature.xml of the referenced feature. As well, all files contained in the referenced feature's Binary Build list (bin.includes) will be included in your feature. If your feature already had license files, you can remove them.

PDE build model API Calling getBuildModel() on IPluginModelBase objects will now return a handle to PDE's build model for that plug-in. The IBuildModel API can be used to view and edit the contents of a build.properties file.

Launching

Default workspace locations If you want to run multiple JUnit Plug-in Tests or Eclipse Application launch configurations in parallel, you need to make sure the launch configurations use separate workspaces.

Configure defaults link

On the Plug-in Development preference page, you can choose the default workspace location for new launch configurations. If you select "Append launch configuration name to this location", you will get separate workspaces for different launch configurations.

Plug-in Development preference page

Applications do not require UI to launch When launching an Eclipse Application or JUnit Plug-in Test you can now select an application to run. Previously, the application framework required UI plug-ins to run, forcing launch configurations to add additional dependencies. In 3.7, applications that run headless (without UI) will not require UI plug-ins to be available.

Select application on launch

Editable source attachments By default, the source attachment for Plug-in Dependencies is a source bundle in the target platform. You can now change the source attachment during development.

While developing or debugging, if a class file is opened that has no attached source available, you can now set a custom source location. Class file editors provide a button to do this, but the source attachment can be modified at any time by right clicking on it and selecting Properties. Changes are not persisted between workspace restarts.

Import

Import from repository uses Eclipse CVS support When using the Import Plug-ins and Fragments Wizard there is an option to import projects from a repository. This option searches for a custom header in the plug-in manifest to find a repository to check out source from. This feature now uses API from Eclipse CVS to perform the import. The import now uses several CVS features including finding alternative repository locations and password storage.

Import plugin from CVS

Target Platform

p2 Target definition performance Target definitions that use a p2 repository as a location will see improved performance in 3.7. Previously, each time a p2 target definition was opened, the remote repository was accessed to determine if all required plug-ins were available. Now, this information is stored locally in a p2 profile.

If the target definition is modified or a required plug-in cannot be found, the target will do a full resolve operation, accessing the remote repository and downloading any missing plug-ins.

Target Resolution
Offline p2 target definitions As an added benefit to performance improvements of p2 based target definitions, the target editor is much more functional with an intermittent network connection. Once a target definition has connected to the remote repository and downloaded all required plug-ins, a network connection is no longer required to open the editor, set the definition as the target platform, and in some cases even modify the target.
Update target definitions Target definitions that contain p2 repository locations can be updated to use the most recent version available. To update a target, press Update on the locations tab of the target definition editor. If a specific location or software item is selected, only that item will be updated, otherwise all locations will be updated. If a newer version cannot be found in the repository, your target will not be changed.

Update button for target definitions
Targets use local repositories When a target definition that contains a p2 repository location resolves, plug-ins must be downloaded to a local cache. However, many of the required plug-ins may already be available locally. Target definitions will now try to copy local plug-ins from the running Eclipse instance or known workspaces instead of downloading them remotely.
Software sites collaborate Previously, Software Site locations in target definitions considered only one repository when looking for dependencies. Now, the repositories from all Software Site locations in the current target definition are used when resolving dependencies.
Source for target definitions When you create a target definition containing a Software Site location, there is now an option to automatically find and download source for the software items you have selected from the set of repositories known to the target definition. Include source option for target definitions
Target definition export improvements Target Definition exporting has been enhanced to create proper p2 metadata and artifact repositories in the destination (for Software Site content), to honor content (de)selection and to allow non-active target definitions to be exported.

API Tools

Include lists in Ant tasks API Tooling Ant tasks that support exclude lists now also support include lists. The include list seeds the set of bundles and members to be analyzed (when omitted, all bundles and members are included), and the exclude list is then applied. Include lists have the same structure as the exclude lists, allowing specific bundles/members, regular expressions and comments to be added.
Consumer use report The API Consumer Use Report Conversion task is a new Ant task that generates an HTML report from the XML result of a use scan. The information is organized in a different format than the standard report converter produces. The references are organized by consumer bundle, the bundle which contains the code that references the API/type. The standard report organizes references by the bundle that produced the API/type.
API use scan builder The API Analysis builder now supports scanning of API use scan reports. Any API use scans added to the API Use Scans preference page will be compared to the current workspace. If any type, method or field references found in the scan have been removed, the builder will report an API Use Scan Problem.

Reports can be added to the page as directories or archives. Only the checked reports are considered by the builder.

API Use Scans preference page

The API Errors/Warnings preference page has a new API Use Scans tab. You can set the severity levels of the reported problems. By default all the problem type severities are set to Ignore. The builder will not check any use scans if all severities are set to Ignore.

API Use Scans severities
Consumer reports in launch configuration The API use scan launch configuration, available under external tools launches, now can create a consumer based report. The consumer based report organizes the use scan references by the plug-in that references the field, method or type (the normal report organizes by the bundle the created the field, method or type). The ant task that creates the consumer report is still available for releng builds.

Consumer Report option in the use scan launch configuration
Ant task to report missing use scan references A new Ant task is available from API Tools that will compare a profile against a list of use scans and report any missing references. A HTML converter task is also available to provide a formatted report. The task will report the same missing references in the IDE when the API Use Scan preference page is used. Documentation for the task is available in the Reference section of the Plug-in Development Environment Guide.
Summaries for API Tools Ant tasks For the API analysis tools that use Ant tasks, you now get a simple index file with summary counts of the kinds of problems found by the tasks.

These summaries are located in the root of the output directory for each scan in a file named counts.xml

Previous     Next