Bugzilla – Full Text Bug Listing
| Summary: | Ensure manifest bundle requires use proper attr key for version | ||
|---|---|---|---|
| Product: | [Tools] Orbit | Reporter: | Thomas Watson <tjwatson> |
| Component: | bundles | Assignee: | Anthony Hunter <ahunter.eclipse> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ahunter.eclipse, aniefer, david_williams, dj.houghton, john.arthorne, Olivier_Thomann, pwebster, remy.suen, tjwatson |
| Version: | unspecified | ||
| Target Milestone: | Helios SR2 | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
| Bug Depends on: | 329376 | ||
| Bug Blocks: | |||
|
Description
Thomas Watson
Looks like we need someone to add a milestone for Helios SR2 to orbit bugzilla. (In reply to comment #1) > Looks like we need someone to add a milestone for Helios SR2 to orbit bugzilla. Done I really do not want to do this work in Helios SR2 as I am not convinced the issue is in just Orbit. We are saying "version" is bad in Orbit, what about all the other bundles? Has the tooling in Eclipse 3.6.2 been updated such that "version" is flagged as an error? With a quick fix to use "bundle-version"? (In reply to comment #3) > I really do not want to do this work in Helios SR2 as I am not convinced the > issue is in just Orbit. That is besides the point. The meta-data is plain wrong for some orbit bundles and this gives you unexpected results even in 3.6 because you basically have no bundle-version ranges specified when you mistakenly used "version". This should be fixed IMO. > > We are saying "version" is bad in Orbit, what about all the other bundles? All bundles. Require-Bundle and Fragment-Host headers should not specify the version attribute when they intended on it being bundle-version. > > Has the tooling in Eclipse 3.6.2 been updated such that "version" is flagged as > an error? With a quick fix to use "bundle-version"? No. Exactly my point Thomas. We are saying the mistakenly usage of "version" is likely an error that will lead to unexpected results even in 3.6. Yet the tooling in 3.6.2 does not complain and allows you to use "version". It is not clear to me how common this is. It could be only orbit, it could be hundreds of bundles in the wild. (In reply to comment #5) > Exactly my point Thomas. We are saying the mistakenly usage of "version" is > likely an error that will lead to unexpected results even in 3.6. > > Yet the tooling in 3.6.2 does not complain and allows you to use "version". I'm confused why that is a argument to not fix the orbit bundles in SR2. > > It is not clear to me how common this is. It could be only orbit, it could be > hundreds of bundles in the wild. True, but shouldn't we fix the orbit ones regardless? Moving out of the Inbox. I guess we are "down to the last second" here; to do for maintenance. Normally, I am in favor of fixing a bundle that can be "silently bad", waiting to byte at any time. But, I am also cautious if there are no known, reported problems in the field. The only problem related to these batik bundles (I know of) is bug 222044. In that case, there were some odd Classcast exceptions that could not be explained. Does this new news explain how those bundles could be getting things "mixed up"? (i.e. wired wrong?) If so, I'd still consider fixing ... though, it is extremely late to be making such a change. I've been hoping I'd have time to test the scenario in bug 222044 with old vs. new bundles, but have not managed to find the time. To answer one of your questions, Anthony. These Batik bundles are pretty much it. I check a large, several thousand bundle adapter product, and no other bundles had the problem. So ... if doing this fix doesn't solve a known problem, I'd suggest we close as "wontfix" ... and encourage everyone to move up to 3.7 stream :) I agree it is getting late. I just hope that none of these bad bundles ever end up being used on a 3.7 Equinox framework. It is a shame we could not get the bad meta-data fixed. I still fail to see the risk in fixing it. (In reply to comment #5) > Exactly my point Thomas. We are saying the mistakenly usage of "version" is > likely an error that will lead to unexpected results even in 3.6. > > Yet the tooling in 3.6.2 does not complain and allows you to use "version". > > It is not clear to me how common this is. It could be only orbit, it could be > hundreds of bundles in the wild. I think there is a misunderstanding here of what the problem is. Manifest headers can have arbitrary attributes, so there was nothing strictly wrong with "version" in the past. It would be equivalent to writing this: Require-Bundle: org.eclipse.core.runtime;foo="[3.4.0,4.0.0)", In 3.6 or earlier, Equinox would ignore "foo", "version", or any other attribute that is not defined by OSGi spec. This is syntactically correct, which is why PDE never complained about it. In the new OSGi spec, those attributes are used by the resolver, so the above import would only be satisfied by a bundle defining a "foo" property. Basically, you have a typo in your metadata. In past releases the typo caused the version range to be ignored, and in new OSGi releases the typo will be treated as a different attribute by the resolver. The net effect is that these bundles *will not resolve* when using an OSGi implementation obeying the latest version of the spec, such as Equinox Indigo. So in conclusion, the only issue would be for an Indigo configuration to use the old Helios Batik bundles, which should not occur as we already have newer bundles in Indigo that we should be using. There could be an issue if someone installed say the Helios GMF into the Indigo platform. In practice this does not happen. The risk here is that we go back to Helios and update bundles for a problem that does not exist. I do not want to invalidate the testing that has occurred since June on the existing bundles. (In reply to comment #11) > There could be an issue if someone installed say the Helios GMF into the Indigo > platform. In practice this does not happen. I wish that were true. Reality is we have products based on Helios which may include GMF from Helios and said products usually have requirements to shell share the base eclipse components with a newer product. That newer product could be based on Indigo and require the new Indigo Equinox to be used for both products. In the end the product owners will have to figure out how to deal with that. |