Updates on Interoperability
Richard S. Hall
heavy at UNGOVERNED.ORG
Fri Apr 25 13:57:02 PDT 2008
Bryan Atsatt wrote:
> Richard S. Hall wrote:
>> Gordon Hirsch wrote:
>>>> 1. Map its dependency declarations into a standard runtime
>>>> 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.
> // Bryan
More information about the jsr277-eg-observer