Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Eclipse Platform Plug-in Development Environment Guide
Previous Page Home Next Page

Layout of Feature Metadata

PDE Build has always used features as a kind of grouping mechanism specifying what exactly should be built. With p2, this idea of a feature as a group has been extended, resulting a more than a single installable unit (IU) being generated per feature.

From build's perspective, a feature contributes three things:
  • A grouping of nested features and plug-ins.
  • The (optional) feature jar itself that contains the feature.xml, license files, etc.
  • A mechanism to contribute root files to the install.

When using the metadata generator introduced in 3.4, we end up with the following structure for feature "org.example.platform":

org.example.platform.feature.group This is the top level grouping IU for the feature, it will have requirements on all the features and plug-ins that were included and required by the feature.xml. It also includes a requirement on the nested org.example.platform.feature.jar
org.example.platform.feature.jar This is the IU representing the feature jar itself. It has an LDAP filter
"(org.eclipse.update.install.features=true)"
which causes the feature jar to only be installed if the profile defines that property. This IU also has a requirement on the actual org.example.platform_1.0.0.jar artifact.

If the feature does not define "bin.includes" in its build.properties file, then this feature jar IU will not be generated.

Notice this IU structure does not include anything for the root files contributed by the feature. Instead a build using the metadata generation placed all rootfiles together into a single IU and artifact.

New in 3.5 is the p2 publisher. If we use PDE Build's eclipse.gatherFeature task to publish the feature from source, we instead get root file IUs corresponding to the feature that contributed them. In this case, we end up with metadata as follows:

org.example.platform.feature.group The top level grouping IU for the feature
org.example.platform.feature.jar The feature jar IU.
org.example.platform_root
org.example.platform_root.<ws>.<os>.<arch>
These are the root file IUs. The feature.group will include a root IU per platform for which the feature contributes files. The root IU itself has a requirement on the actual binary artifact from a p2 artifact repository (eg binary/org.example.platform_root.gtk.linux.x86_1.0.0) that contains the files.

The use of the new p2 publisher instead of the old metadata generator allows for much finer grain control over how root files are delivered for products.


 
 
  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire