Hi Richard,
Richard S.Hall wrote:
...
Perhaps so.
I am operating off my [possibly dated] recollection that 277 modules
explicitly list the classes that they export, which meant that they may
expose arbitrary public classes from a package. If this is no longer
the case, then this is fine.
The point remains, all legacy OSGi dependencies on a package assume
that all public classes are exported from that package. An OSGi
dependency on a given package cannot be resolved to a 277 module whose
"exported public" classes are not the same as all "public" classes in
the specific package.
I was under the impression that the class filtering is also in effect to
determine which public classes are exported from that package in OSGi
and that the OSGi dependency on a package already has a similar
"exported public" concept.
Anyway, these are all related to how the OSGi framework might import 277
modules by package name. I think it would be good to know if this is
actually a sensible thing that the OSGi framework wants to support
before we dive too deep on this. Glyn/Richard, is this something that
you foresee the OSGi framework will support?
- Stanley
