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

Bug 181179

Summary: Notify when an R3 bundle uses OSGi R4 syntax
Product: [Eclipse Project] Equinox Reporter: Danail Nachev <d_nachev>
Component: FrameworkAssignee: equinox.framework-inbox <equinox.framework-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: hargrave, tjwatson
Version: 3.3   
Target Milestone: ---   
Hardware: PC   
OS: Windows 2000   
Whiteboard:

Description Danail Nachev CLA 2007-04-05 07:35:42 EDT
Steps To Reproduce:
1. Create a bundle which doesn't have Bundle-ManifestVersion: 2 header and uses OSGi R4 syntax (Require-Bundle for example)
2. Deploy this bundle
3. Check that everything is fine (classes are loaded through Require-Bundle dependency)

According to the specification, such behaviour is not valid. Bundles w/o Bundle-ManifestVersion must be treated as R3 bundle and certain features described in R4 spec should be disabled.

In the current codebase, the difference between bundles with and w/o Bundle-ManifestVersion is that, those with the header are validated and those w/o aren't. But all headers are still accepted.

I understand that this is hard to change because there are so many bundles without Bundle-ManifestVersion and it is risky to break this behaviour.

However, I think there should be a warning (which should turn into error later) to notify the developer about this.

Otherwise, developers can start report problems when they try to deploy their bundles on another OSGi frameworks.
Comment 1 Danail Nachev CLA 2007-04-05 07:36:23 EDT
I assume that Reference Implementation has the same problem?
Comment 2 Thomas Watson CLA 2007-04-05 08:50:06 EDT
I'm not convinced this is a violation of the specification.  The specification allows for frameworks to implement additional features and recognize additional headers which are not defined by the specification.  When a bundle does not have Bundle-ManifestVersion: 2 then it is processed as an OSGi R3 bundle.  In this case all OSGi Defined headers in R3 must be processed as if the bundle is on an R3 framework.  For example, exported packages must be implicitly imported.   However the framework is allowed to process additional headers if it chooses to which are not defined by the R3 specification.

In Equinox we implemented Require-Bundle (and Fragment-Host) long before R4 was released and the introduction of the Bundle-ManfestVersion: 2 header.  I would agree with you if the OSGi R3 specification said an error must occur if undefined headers are present in a bundle.  Since the specification makes to assertion it would break R3 backwards compatibility to start publishing errors for headers which are not defined in R3.
Comment 3 Danail Nachev CLA 2007-04-05 09:29:03 EDT
You are perfectly correct. It is indeed not in violation of the R4 spec contract. I'm more thinking about some mechanism, which notify the users that they are mixing R3 and R4 content and should put Bundle-ManivestVersion.

I was hoping that the migration from one OSGi implementation to other could be made easier.
Comment 4 Thomas Watson CLA 2007-04-05 09:55:26 EDT
I will reopen and change the title to refect what is desired.  I still do not think this is something we can enable by default because the log will fill up with errors/warnings for configurations that do not violate the specification.
Comment 5 Thomas Watson CLA 2007-04-05 09:57:22 EDT
I also think this is something more suited for tooling.  PDE (or other bundle builders) should give a warning or error when this is detected.
Comment 6 Thomas Watson CLA 2007-04-05 10:34:01 EDT
I opened PDE bug 181210 to provide a warning at development time.
Comment 7 Danail Nachev CLA 2007-04-05 10:40:55 EDT
Yes, I did that too:))

https://bugs.eclipse.org/bugs/show_bug.cgi?id=181182

I think it will suitable to display such warning when the framework is run in debug mode.
Comment 8 Thomas Watson CLA 2018-01-08 13:53:07 EST
No plans to do this for R3 bundles.  R3 is really old at this point and likely no need to add enhancements for debugging stuff like that.