[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] RequiresBundle, ImportPackage and virtual providers
- From: "Alex Blewitt" <alex.blewitt@xxxxxxxxx>
- Date: Fri, 31 Mar 2006 08:40:24 +0100
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=WC2aSENIkDFm9hus13LNFdb05yLOpWqTuIiFHQxJs1mSC2qMDea5BtcRdXbTJKWt9VdAkdKzOSflmuo+v9SlJpFIAD4IqoZSzf5Nc+Duab/ppqhi227EG4Mpp2P5yXqSXot+GCYjvK2dgcBm89Q8IwUnP0kzBp17x9dWptqdeNY=
On 31/03/06, Niclas Hedhman <niclas@xxxxxxxxxxx> wrote:
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
Probably a good idea. Thanks, I'll take my thoughts off-list.