Community
Participate
Working Groups
We should consider a warning for use of the old Eclipse-GenericRequire and Eclipse-GenericProvide manifest headers. A quick fix could offer to replace these with the standard OSGi Require-Capability and Provide-Capability headers.
The mapping between Equinox-Generic Require/Provide headers is not a simple conversion. The Equinox Generic syntax had a encoded two pieces of information into the the type-name (see http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html) 1) the "name" of the capability 2) the "type" of the capability (optional, defaults to "generic") In the generic Require-Capability/Provide-Capability headers from osgi we have to map the "type" to a namespace and the "name" becomes a simple attribute: Eclipse-GenericCapability: my.capability:my.type; version:version="1.0"; my.attr="my.value" Converts to this: Provide-Capability: my.type; my.type="my.capability"; version:Version="1.0"; my.attr="my.value" And this for a simple requirement: Eclipse-GenericRequire: my.capability:my.type; selection-filter="(&(version>=1.0")(my.attr=my.value))" Converts to this: Require-Capability: my.type; filter:="(&(my.type=my.capability)((&(version>=1.0")(my.attr=my.value))) But keep in mind that the "type" is optional for the Eclipse headers. But it is absolutely required for the OSGi headers and equates to the capability namespace. So if the colon : is left out then the type/namespace defaults to the string "generic". I realize this is probably not that clear, but I wanted to give some idea of what is involved to do this quick fix conversion.
Do you think the warning makes sense though Tom? I just thought it would be useful to steer people towards the OSGi standard headers over Eclipse-specific ones..
(In reply to comment #2) > Do you think the warning makes sense though Tom? I just thought it would be > useful to steer people towards the OSGi standard headers over Eclipse-specific > ones.. Yes, I think a warning would be a good and could be done without the quick fix.
I can't change the 'status' or 'assigned to' fields to myself, but I'm happy to help.
Curtis, I've delivered a number of fixes in the following commits to https://github.com/ind1go/eclipse.pde.ui : 2ba19724427052f21a421b85423f77e52fe29822 Correct spelling mistake in "Eclipse-GenericCapability". 08397e63a2c39f45c95769bef18dbb2458c9bbe6 Add basic manifest content assist for Require-Capability and Provide-Capability. e4e5893ac3377862df10e775eebc77508aa7aaf9 Add warning for Eclipse-GenericCapability and Eclipse-GenericRequire, instead pointing to Provide-Capability and Require-Capability. 6ea0c59aa95dce9623161d4db19fc23ca4341372 Make the deprecated warning for Eclipse-GenericCapability and Eclipse-GenericRequire only enabled when the target is >= 3.7 I wrote all the code above and have the rights to contribute it to Eclipse under the eclipse.org web site terms of use. It offers a warning of deprecation, but doesn't have a quick-fix yet. I'm happy to make one, but it'll require a ProvideCapabilityHeader/RequireCapabilityHeader model. Will I be stepping on anybody's toes if I make them?
Thanks for the contribution Ben. In the future, please make it easier for me to cherry pick the necessary commits by either having them in a separate branch or starting the commit message with the bug number. This only applies if a contribution is split over multiple commits. Fixed in master.
Verified in I20111021-1625
