Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 328508

Summary: Add support to Require-Bundle for arbitrary matching attributes and mandatory directive
Product: [Eclipse Project] Equinox Reporter: Thomas Watson <tjwatson>
Component: FrameworkAssignee: Thomas Watson <tjwatson>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: dj.houghton, hargrave, Olivier_Thomann
Version: 3.7   
Target Milestone: 3.7 M4   
Hardware: PC   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:
Attachments:
Description Flags
proposed fix none

Description Thomas Watson CLA 2010-10-22 15:46:53 EDT 
You guessed it!  OSGi decided that Require-Bundle should be consistent with Export-Package/Import-Package and support arbitrary matching attributes and the mandatory directive.

So now we need to support arbitrary attributes on Bundle-SymbolicName as well as the mandatory directive which can be used to specify mandatory matching attributes in order to be resolved to a particular bundle symbolic name.  Oh joy!
Comment 1 Thomas Watson CLA 2010-10-26 16:58:49 EDT 
Created attachment 181780 [details]
proposed fix

Here is a proposed fix.  I have added tests to the OSGi CT (not equinox test bucket) to test this.
Comment 2 Thomas Watson CLA 2010-11-01 14:36:00 EDT 
Patch release.
Comment 3 Thomas Watson CLA 2010-11-03 11:37:05 EDT 
This has caused issues in a p2.test bundle.  See bug329361.

Some bundles are incorrectly using the "version" attribute in the Require-Bundle header instead of "bundle-version".  In previous releases of the Equinox framework this would result in the unknown "version" attribute to be ignored.  For example:

Require-Bundle: org.eclipse.foo; version="[1.0,2.0)"

In previous versions of the framework the "version" attribute was completely ignored by the framework and any bundle-version of org.eclipse.foo could be used to resolve the require-bundle constraint.

Now with the support for matching arbitrary attributes in Require-Bundle the above Require-Bundle is treated differently.  Now the unknown "version" attribute will be treated as an arbitrary matching attribute and the framework will look for a Bundle-SymbolicName which has the symbolic name org.eclipse.foo AND specifies the "version" attribute that can match the string "[1.0,2.0)".

I will need to send a note out to cross-project list stating the change in behavior and the potential impact.  The reality is that such bundles that incorrectly use "version"attribute were not getting the behavior that they expected.  They need to fix their manifest.  The good news is that PDE will now flag such incorrectly specified Require-Bundle statements as unresolvable.  The bad news is that the error message is not clear that it is because of a failure to match a specific matching attribute.  The perhaps worse news is that an unknown (hopefully very small?) number of bundles will fail to resolve on 3.7 where they could resolve (perhaps incorrectly) on 3.7.