Re[2]: [equinox-dev] RequiresBundle, ImportPackage and virtual providers

[Peter Kriens <Peter.Kriens@xxxxxxxxx>]

Packages can also be sealed separately:

http://java.sun.com/developer/Books/javaprogramming/JAR/basics/manifest.html#sealing

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
packages.

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>  
AB>  
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>  
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@xxxxxxxxxxxxxxxx.
AB>  

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

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