I'm not sure you ever got answers to some of your questions ... so, just in case you still need them ....
> I noticed long ago that MANIFEST.MF as shipped by SimRel bears > little resemblance to my source text. There is a nasty line-wrapping > and every class has an SHA1-Digest added. The "wrapping" is part of the "spec" for MANIFEST.MF files and any build and any runtime version should be wrapped that way (that is, not exceed 80 characters ... how old is that! :) The SHA Digest is part of the "code signing" that occurs ... again, any build that "signs" would have these. So, these first two aren't specific to Eclipse, OSGI, or Sim. Release, or anything other than "Java". > If something is rewriting all the Import-Package directives, then > surely it could/should rewrite all the Export-Package directives to > use "uses" too? There are actually some "build tools" that will do that, such as BND ... I think its called ... and not sure if by default, or if you have to spell it out ... BUT, we discussed this in Orbit (at least in Orbit, other projects may have also) and decided against a blanket "always use uses-clauses" because there was some concern that if it was ALWAYS used, then it would start to have a performance impact ... not so much for "small apps" of several hundred bundles ... but, for cases where several thousand bundles were being used, it might start to add up, especially to start-up time, and especially to "first time" start-up time. That was many many years ago, so not sure if there has been any studies or improvements in that concern. But, it is also clear that in some cases, it is definitely required, to get components to "play nice" with each other. I'm sorry I don't know of a clear statement of "how to know" when its required, and when its not ... but if there is one, I bet a search engine would find it. (including some interesting, old, bug reports :) HTH From: Ed Willink <e...@willink.me.uk> To: Cross project issues <cross-project-issues-dev@eclipse.org>, Date: 06/04/2014 07:21 AM Subject: Re: [cross-project-issues-dev] Pseudo-singleton for Guava in RC3 Sent by: cross-project-issues-dev-boun...@eclipse.org Hi David On 04/06/2014 11:48, David M Williams wrote: > I think that someone with the power to influence the platform needs to review how > we support Guava and other shared non-singletons > so that we avoid repeating this mess in Mars. Hmmm, I think, Ed, I finally found one thing to disagree with you about :) Hopefully we're agreed about trying to avoid this mess in Mars. If tooling rather than the platform is the solution, fine by me. I think if you (or others) carefully read Bug 427862 you'd find this issue less about "using one version" and more about using correct versions, in correct ways: a) projects should follow "best practices" for componentization (such as, 1) do not "re-export" bundles simply for a convenience, 2) don't make "third party" code part of your own API (unless it's one that's mature, and one that can be well trusted to follow OSGi principles), 3) use proper version ranges when exporting or importing packages, 4) take advantage of "uses clauses", etc.) and b) we need to influence those third parties who are not using OSGi quite right, and encourage them to do so (which has happened, in this case!) Thanks for pointing back at this. I didn't understand "uses" and got Marcel to give a better example. I see that the Manifest editor has a "Calculate Uses" button that makes my Manifests huge. I don't particularly want to maintain this manually. I noticed long ago that MANIFEST.MF as shipped by SimRel bears little resemblance to my source text. There is a nasty line-wrapping and every class has an SHA1-Digest added. If something is rewriting all the Import-Package directives, then surely it could/should rewrite all the Export-Package directives to use "uses" too? Regards Ed Willink _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev