Relationship to JSR 291 [was: Re: Bryan's comments]
Stanley M. Ho
Stanley.Ho at sun.com
Thu May 31 15:35:00 PDT 2007
Richard S. Hall wrote:
> I am not so sure supporting #3 is as straight forward as you suggest
> here. Specially, the OSGi modularity layer [for the most part]
> assumes that packages are atomic units; there is no way to specify
> that your export or import something smaller than a package. Since
> 277 modules declare exports in terms of classes, it is not clear how
> we would know if a 277 module was exporting an entire package. This
> would, at a minimum, require that we assume we can inspect the
> contents of the module and see that the contents of a contained
> package matches the module's export signature for that package.
My assumption for #3 is that if an OSGi bundle attempts to import
package x.y.z and if the OSGi framework wants to resolve such dependency
using 277 modules, it can search all the modules in the repositories to
find out which module have exported classes that are in package x.y.z.
After the appropriate 277 module has been identified, the OSGi framework
can do whatever is needed to wire that 277 module. Obviously, searching
modules in the repositories this way may not be very efficient, and it
may make sense to have some convenience methods in this case to make it
easier for querying modules by package name.
I don't think I fully understand your concerns around exporting an
entire package. As you mentioned, what's get exported in 277 module is
in terms of classes and the information is in the module metadata, and I
think we can probably determine the packages associated with these
exported classes and treat these packages as "exported packages" from
the OSGi perspective. There is no split package allowed in 277 module,
so I think each of these exported packages would be an entire package.
More information about the jsr277-eg-observer