## Feature manifest editor

The feature manifest editor uses the same concepts seen in the other PDE editors. It has four form pages (Overview, Information, Content and Advanced) and a source page that shows you raw XML code of the manifest file. If build.properties file is present in the project, additional page (Build) shows up allowing you to configure how the feature will be built. Source page for the build.properties file will also appear in this case.

Information that is entered during the feature project setup can be changed on the Overview page. In addition, you can provide URLs for update site and discovery sites in the property sheet. The update site URL is used by the Update Manager when searching for new updates. The discovery site URLs are used to point users to other interesting features and/or sites.

You can provide your own banner image that will be used in the Update Manager when users browse your feature. If you mark the feature as 'primary', it will be treated as a 'product' feature and will have additional responsibilities (providing 'About' information, splash screen etc.). Finally, you can require an exclusive install for your feature if it should be take part in batch installation (several features at once).

Branding information for primary features is stored in a branding plug-in. If not explicitly set, Eclipse will assume that the branding plug-in has the same identifier as the feature.

By default, your feature is treated as universally portable. You can add constraints by providing supported operating/windowing systems, languages and/or system architectures. This information will be used to ensure that your feature is not installed or shown in the context that does not match these constraints.

Features are required to provide description, license and copyright information. This information can be edited on the Information page. Each of these three categories can be represented as either text or a URL that points to a valid HTML page. Although URL can be absolute, HTML pages are typically provided with the feature and URLs are relative to the project root.

Plug-ins and fragments that are part of your feature are listed in the Content page. Pressing the Add... button brings up a list of checkboxes representing all of the valid plug-ins and fragments in the workspace. If you double-click on a plug-in or fragment entry, the plug-in or fragment manifest editor will open for the selected item.

Required plug-ins are plug-ins that are not part of the feature but must be present in the target platform as a prerequisite for installing the feature. If any of these plug-ins are missing, the feature will not be installed. Required plug-ins can be computed based on collective dependency information in plug-ins and fragments, or added manually using the Add Plug-in... button. The requirement can be based solely on plug-in IDs, or further constrained using expected versions and match rules.

Similar to plug-ins, features can be used as prerequisites. Similar rules apply. The distinct difference is that feature dependency is required when patch checkbox needs to be selected. See feature manifest reference for more details.

In addition to these standard pages, feature manifest can be used to set more advanced feature manifest data. Larger features may be built by including other features, thus creating a feature hierarchy. In addition to plug-ins, opaque data entries can be specified to carry custom feature information. These entries usually come together with custom install handlers. Install handlers can be used to perform non-standard install tasks and manipulate data entries once they are downloaded by the Update Manager. You can read more about this and other feature issues in Platform Install and Update guide.