Thanks to Niclas and Richard for their comments. The background of my questions is that I want to express the rules one has to follow when specifiying the dependencies of bundles to avoid later runtime errors.
The simple rules are: [1] A bundle may export a package that it contains [2] A bundle may import a package that it exports to allow substitutions [3] A bundle may only specify "uses" of packages (in export definitions) that it imports or exports These rules are _local_ rules in the sense that you can check whether the rules are met by inspecting the bundle in question. Now what about reexport of packages? Consider the following rule: [4] A bundle may export a package that it imports Now this is a _non local_ rule because it is quite easy to construct examples that rule [4] is true, but the overall specification of dependencies is not sound. Does the OSGi specification allow [4]? With Require-Bundle one can reexport the imported packages from the required bundle. But the situation is different: As long as the required bundle follows the rules [1] - [3] there is no problem. So is the following rule the right one? [4'] A bundle may only reexport packages imported from required bundles -- Burkhardt Richard S. Hall wrote: > Burkhardt Renz wrote: >> Hi, >> >> I try to understand the OSGi specification -- and during that >> process I have some questions, which may be trivial, but it seems >> that they are not explicitly addressed in the specification. >> >> [1] The resolving process, as described in 3.7 of the spec, >> tries to wire bundles according to the constraints given in >> the manifests of the bundle. Is this process based _only_ >> on the declarations in the bundles' manifests? >> > > Yes, > >> [2] It seems obvious that a bundle may export some package, >> that is containted in the bundle. And it can import the >> very same package, to allow the substitution of the package. >> Can a bundle export a package that it does _not_ contain, >> i.e. _reexport_ an imported package? >> > > Yes, this is possible with require-bundle. > >> [3] An Example: >> Bundle0: contains P0, imports P0 >> Bundle1: exports P0, imports P0 >> Equinox wires Bundle0 to Bundle1 for P0 >> The consequence are errors at runtime. >> Does the OSGi Specification take for granted, that developers >> don't do things like in this example? >> > > The spec assumes that you follow the rules set by the spec. So, if you > give faulty metadata, then you only have yourself to blame. > >> [4] When the framework tries to resolve the dependencies of >> a new installed package, does it _recalculate_ the wiring between >> bundles that it has already established? >> > > The spec may allow this, but it does not require it. In many cases you > would not want to recalculate already established wiring, because it > would require bringing down bundles, which is disruptive. However, in > some cases, it may not be possible to load new functionality without > re-wiring existing bundles. > >> [5] With respect to the uses directive in the Export-Package statement >> Richard S. Hall writes in a message in this mailing list: >> "Bundle B: Export Package: com.osgi.P1;version=1.0.0;uses:=P2; >> For P1 in Bundle B to use P2, Bundle B must either export or import P2, >> but in your example above it does neither, so this is not a valid >> example." >> Is the rationale behind that comment, that if P1 uses P2, then P2 has to >> be contained in the bundle (and has to be exported) or that this is not >> the >> case (and therefore Bundle B has to import P2)? If yes: why does Richard >> say "either...or", could not be both? >> > > Yes, that is an inclusive "or"...sorry for any confusion. > > -> richard _______________________________________________ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
