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