[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re[2]: [equinox-dev] RequiresBundle, ImportPackage and virtual providers

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! :-)

Kind regards,

     Peter Kriens

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> osgi-dev@xxxxxxxxxxxxxxxxx

AB> Probably a good idea. Thanks, I'll take my thoughts off-list.
AB> Alex.

Peter Kriens                              Tel +33870447986
9C, Avenue St. DrÃzÃry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599