Community
Participate
Working Groups
In Luna we removed the compatibility with old style Eclipse 2.0 plugins. We also removed support for some interim headers and attributes. For example, the following: Provide-Package header: Was an interim header to specify packages provided to requiring bundles. This header just got merged into Export-Package in the final spec. In Kepler if this header was present we tried just like Export-Package. In Luna we now ignore it. Singleton attribute: Initially singleton was specified as an attribute on the Bundle-SymbolicName header. The singleton directive was ultimately included in the final specification, not the singleton attribute. In Kepler we support specifying singletons as both a directive and attribute: Bundle-SymbolicName: foo; singleton:=true or Bundle-SymbolicName: foo; singleton=true In Luna we now only recognize the singleton directive. If singleton=true is specified it is just treated like a normal capability attribute. Require-Bundle reprovide attribute: Initially to reexport a bundle from Require-Bundle the attribute reprovide=true was specified. In the final OSGi spec this was changed to a visibility directive with a reexport value: Require-Bundle: foo; reprovide=true Should be: Require-Bundle: foo; visibility:="reexport" Require-Bundle optional attribute: Initially to require a bundle from Require-Bundle or a package from Import-Package optinally the attribute optional=true was specified. In the final OSGi spec this was changed to a resolution directive with an optional value: Require-Bundle: foo; optional=true Should be: Require-Bundle: foo; resolution:="optional" I would prefer to no longer support these interim headers/attributes. Unfortunately it looks like a number of bundles in eclipse use these. If we do not support them then it probably makes sense to try and log an error when they are detected to make it much more in your face when a bad bundle is installed.
(In reply to Thomas Watson from comment #0) > If we > do not support them then it probably makes sense to try and log an error > when they are detected to make it much more in your face when a bad bundle > is installed. That might be appropriate at M6 provided: At M5 we get API tooling warnings. And/Or one of David's magic scripts reports all obsolete usages in the aggregation.
> Bundle-SymbolicName: foo; singleton=true In my workspace, I saw this in 3 tests in org.eclipse.core.tests.runtime. > Require-Bundle: foo; resolution:="optional" In my workspace, I only see this format in org.eclipse.osgi.services. Everybody else uses the unquoted form: resolution:=optional Since a colon is easy to miss, this should at least be announced in the compatibility guide. A log entry would also be nice.
Tom these changes went into the framework in Luna M1 right? I.e., is there a new issue in M4 or was it just recent discovery of some invalid attributes in our bundles?
(In reply to John Arthorne from comment #3) > Tom these changes went into the framework in Luna M1 right? I.e., is there a > new issue in M4 or was it just recent discovery of some invalid attributes > in our bundles? It has been this way since M1. It was brought to my attention by bug 421706 not by the bundles actually contained in the equinox/equinox projects.
(In reply to Markus Keller from comment #2) > > Bundle-SymbolicName: foo; singleton=true > > In my workspace, I saw this in 3 tests in org.eclipse.core.tests.runtime. Using the singleton=true attribute in tests likely is not going to have a visible behavior issue unless the test is exercising singleton resolution. It may also cause issues if the test bundle contains extensions. The eclipse extension registry only pays attention to singleton bundles. > > > Require-Bundle: foo; resolution:="optional" > > In my workspace, I only see this format in org.eclipse.osgi.services. > Everybody else uses the unquoted form: > > resolution:=optional Quotes are not strictly necessary unless the value of the directive/attribute contains one of the delimiter tokens (e.g. ';' ',' space etc.). So in this case having 'optional' unquoted is still valid. > > Since a colon is easy to miss, this should at least be announced in the > compatibility guide. A log entry would also be nice.
I admit it, I am caving in on this one. I anticipate that removing support this will lead to several hard to diagnose issues down the road so I am adding support back in M6. Tests added with: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=d0c99cf6dc146ca1d77199a7e4c9e3c43efe911b Updated manifest parser to recognize old header/attributes with: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=de721749d9304e126479984ede4be710b35d5ab5
