[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] RequiresBundle, ImportPackage and virtual providers
- From: Peter Kriens <Peter.Kriens@xxxxxxxxx>
- Date: Fri, 31 Mar 2006 10:23:17 +0200
- Delivered-to: email@example.com
- Organization: aQute
Packages can also be sealed separately:
But this is not really necessary, in an OSGi Framework you will have to work
VERY hard to mix package content (split packages). The default is to treat an
exported/imported package as an atom. And the "uses" allows you to group
Hey come on! We did not spent 7 years to come up with the same problems of
the standard classpath! :-)
AB> On 31/03/06, Niclas Hedhman <niclas@xxxxxxxxxxx> wrote:On Friday
AB> 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.
AB> Sign and Seal.
AB> You don't sign and seal packages. You sign and seal *Jars*. The
AB> problem is that if you have an Import-Package, you're opening
AB> yourself up to potential pollution of an unversioned namespace,
AB> even when you've signed the Jar file. All signing a Jar file does
AB> is to prevent additions to that Jar; it does *not* prevent
AB> additions to that package by other Jars.
AB> 2. Since I am not very fond of the coupling of RequireBundle at all, I should
AB> probably not take part in the argument.
AB> Well, I was looking for views from other's point of view, so it
AB> was useful for me. Indeed, one of the reasons why I proposed it
AB> here was to be able to use bundles but with a weaker coupling
AB> method; not to replace services, nor to replace Import-Package,
AB> but as a half-way between the two.
AB> 3. I think your input will actually be a lot better received by the JSR-291
AB> Expert Group, as the JSR does not cover the Service layer. I suggest that you
AB> take the effort and publish a more official web page of what you have in mind
AB> than rabbling on this list ;o), and then post a pointer on
AB> Probably a good idea. Thanks, I'll take my thoughts off-list.
Peter Kriens Tel +33870447986
9C, Avenue St. DrÃzÃry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599