Hi Bryan, Bryan Atsatt wrote:
Let me clarify. It is my assumption that 277 will provide both an API/framework *and* a specific ModuleSystem implementation. And that OSGi will be able to supply another ModuleSystem implementation:277 API/Framework / \ / \ 277ModuleSystem OSGiModuleSystem
Right. There are also other module systems that can be plugged into this framework, e.g. NetBeans.
Therefore, the API's must *support* "import package", or it will not be usable by the OSGiModuleSystem. I agree that the 277ModuleSystem implementation does not need to support "import package" semantics. Which means that the 277 APIs must support *both* semantics. Otherwise, OSGi will not be able to operate as a first-class citizen in the 277 world. And, if 294 adds support for "import", it should at least do the natural thing of "import package". And it should also support "import module", but supporting both at the language level may be awkward. // Bryan
I think we all agreed that the module system defined by JSR 277 does not need to support import package. As far as I am aware (correct me if I'm wrong), all the existing systems support import at the module level, and OSGi is the only one that supports import at the package level. Thus, import by package should be a feature specific to the OSGi specific module system implementation (e.g. OSGiModuleDefinition), and I don't think it is necessary to push it into the base classes in JSR 277. This doesn't mean supporting the notion of import by package is impossible. What OSGi will expose from its repository is simply module definitions, and module definition is basically an abstraction. Therefore, it should be possible to treat an OSGi bundle as a module definition, as well as to treat each exported package in an OSGi bundle a module definition as well. The dependency supported in JSR 277 is import-by-module. In the JSR 277 module system, this is mapped to import-by-superpackage. In the OSGi module system, this can be mapped to import-by-OSGi-bundle or import-by-package. If other module systems want to support different import granularity or if OSGi evolves to add new import granularity in the future, this model should still work. Honestly, interoperability between multiple module systems with "import module" alone is already a hard enough problem for us to solve. I am concerned that we're making this problem towards insolvable if we keep adding complexity. ;) - Stanley
