On Friday 31 March 2006 07:04, Alex Blewitt wrote:
> This is the key problem, for me. A package is an open-ended bucket, to
> which not only this bundle, but *any* bundle, can contribute classes
> to. It's an implementation facet. There's nothing to stop other
> bundles inserting (or attempting to replace) items in this package on
> a piecemeal basis. A bundle, on the other hand, is a closed collection
> of code that I can depend on as a black-box unit. A package is *not* a
> black box.
Sign and Seal.
You don't sign and seal packages. You sign and seal *Jars*. The problem is that if you have an Import-Package, you're opening yourself up to potential pollution of an unversioned namespace, even when you've signed the Jar file. All signing a Jar file does is to prevent additions to that Jar; it does *not* prevent additions to that package by other Jars.
2. Since I am not very fond of the coupling of RequireBundle at all, I should
probably not take part in the argument.
Well, I was looking for views from other's point of view, so it was useful for me. Indeed, one of the reasons why I proposed it here was to be able to use bundles but with a weaker coupling method; not to replace services, nor to replace Import-Package, but as a half-way between the two.
3. I think your input will actually be a lot better received by the JSR-291
Expert Group, as the JSR does not cover the Service layer. I suggest that you
take the effort and publish a more official web page of what you have in mind
than rabbling on this list ;o), and then post a pointer on
osgi-dev@xxxxxxxxxxxxxxxx.
Probably a good idea. Thanks, I'll take my thoughts off-list.
Alex.
