Hi Richard, 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. - Stanley
