A feature is the only level of installable unit that exists. You cannot choose to install only certain plug-ins from a feature. The Plug-in Development Platform provides wizards for creating Features.
Once the feature project is created, you can make additional updates to the feature definition by editing the feature.xml
Additionally, if a feature has already been created, you can import the feature as a binary project into your workspace. Select File > Import > External Features
to launch the wizard. Enter the name of an update site to browse, and you can select the features to import.
Importing External Features is useful if you are attempting to create an Update Site, and someone else has already created the features that need to be installed.
To enable Lotus® Expeditor users to use the Scan for Updates action within the Application Management dialog, you must add an update URL to the feature.xml
file. Using the Feature Manifest Editor, on the Overview tab, right click on the Update URLs
entry in the Feature URLs section, then select New > Update URL
. You can then enter the appropriate update site information in the Properties view that is displayed.
If no update URLs are provided in the feature.xml
file, the Scan for Updates action will still be displayed as an available action, but will not return any update information.
Lotus Expeditor uses the rcp
directory to contain all of the features and plug-ins from Eclipse as well as the features and plug-ins that are part of the client platform. The shared directory can be used to install features that are to be used by all users on the client system. Additionally, there is a feature install directory in the workspace associated with each user.
When new versions of features are provided, they will be installed into the same directory as the previous version. The installation directory for a feature upgrade cannot be changed.
Versions for features are specified using major.minor.service.qualifier
. For example, a version of 4.0.1 has a major version of 4, a minor version of 0, and a service version of 1. An equivalent version is a version that differs first at the service level. A compatible version is a version that differs first at the minor level. For example, using our version 4.0.1 above, a version of 4.0.2 would be an equivalent version, since the service value is the first value that changed. A version of 4.1.2 would be a compatible version, since the minor value is the first value that changed.
The Scan for Updates capability provided as part of the Application Management dialog enables updates of only equivalent or compatible versions, according to the preferences selected in the Manage > Preferences > Install/Update dialog
. The default value is for Equivalent feature updates.
A feature version that changes at the major level, for example, a version 5.0.0 that would replace our version 4.0.1, must be installed through the Application > Install
mechanism. Scan for Updates will not show this feature as being available.
For additional information on versioning, refer to the Feature manifest
section of the Platform Plug-in Developer's Guide
, and the Getting Started > Features
section of the PDE Guide .
Parent topic: Understanding the types of install artifacts: XPD621