Updates on Interoperability

[Richard S. Hall]

Bryan Atsatt wrote:
> Richard S. Hall wrote:
>> Gordon Hirsch wrote:
>>>> 1. Map its dependency declarations into a standard runtime 
>>>> representation.
>>>> 2. Support a standard search model over its stored modules, using 
>>>> the runtime dependency expressions.
>>>> 3. Map its stored module data into a standard runtime 
>>>> representation that can be returned by the search.
>>>
>>> One challenge lies in defining the "standard runtime 
>>> representations" and "standard search model" in a universal enough 
>>> way to encompass OSGi and other module systems. This implies 
>>> embracing concepts (in these standard representations and search 
>>> model) that were not universally liked by the EG early on. (Split 
>>> packages and package-level import/export come to mind.)
>>
>> Package-level import/export seem like a must, but I still don't see 
>> split packages as a necessity.
> Strongly agreed on import-by-package, and that ModuleDefinition 
> requires a method to enumerate exported packages (and probably an 
> exportsPackage(String packageName) method to enable an efficient Query).
> On the split package front, however, it seems a little fuzzy to me. If 
> an OSGi implementation of 277 is also going to remain OSGi Rx 
> compliant, it will still need to support split packages, right? If so, 
> don't we need to surface this fact at the 277 level? Perhaps that is 
> as simple as acknowledging that Module.getImportedModules() may return 
> more than one instance that exports a given package.

That all depends on if the 277 API is a subset of OSGi functionality or 
equal to it, I suppose.

-> richard
>
> // Bryan