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
