Hi Bryan,
Bryan Atsatt wrote:
...
Rather than surfacing the import-by-package at the API level, I think we
can solve #3 by generalizing the import dependency concept as
import-by-name, and this name can be mapped to superpackage-name in JSR
277 and OSGi-bundle-name or OSGi-exported-package-name in OSGi (i.e.
exposing OSGi bundles and exported packages through implementing
OSGiBundleModuleDefinition and OSGiPackageModuleDefinition). I think
this is also what you intended to say at one point (correct me if I
misunderstand you) by suggesting to change
ImportDependency.getModuleName() into something like
ImportDependency.getName().
I believe we are now thinking along the same lines.
Good to know.
I just sent an email on the topic of generalizing the import dependency
concept, with the subject "Import constraints". With the approach I
suggest there, the distinctions between module-name and package-name are
mostly transparent to the runtime (declarative support for package-name
is not addressed).
I will reply to that thread later.
In case if the 277 module would like to import these OSGi exported
packages using an OSGi-like resolution algorithm, it should be possible
for it to use a custom import policy (or import override policy or maybe
some new override mechanisms) to get the behavior it wants.
Do you think this is a workable approach to address #3?
I don't think custom code should be required; we need to make it easier
than that or it doesn't qualify as "first-class" citizenship, at least
not to me :^).
The OSGi resolution algorithm has evolved significantly between R3 and
R4, and it will likely continue to evolve in certain degree in future
releases (Glyn/Richard, please correct me if I'm wrong). From this
perspective, I don't think it makes sense to have build-in OSGi-like
resolution algorithm in 277, because it will stick forever once 277 is
part of the SE platform and cannot be evolve easily.
I think it would makes more sense to allow OSGi-like resolution logic to
be plugged into the 277 module which imports OSGi bundles/packages. We
could argue whether it should be plugged in per-module in the form of
custom import policy, or per-system(or per-repository?) in the form of
import override policy, or maybe even have a new mechanism to allow
certain class of modules (e.g. 277 modules importing OSGi modules, or
277 modules importing NetBeans modules, etc.) to always use a specific
import policy automatically. But my point is that OSGi-like resolution
logic is something that will need to evolve in the future and should not
be built-in. I think if there is a way to plug in OSGi-like resolution
logic into 277 module which imports OSGi bundles, it would still qualify
as "first-class" citizenship to me. ;)
And we don't yet have *any* import declaration mechanism (yes, we're
assuming that this will be handled in 294, but it hasn't been brought up
yet). I don't see this as a difficult issue either way. It would be
natural to have both import-by-name and import-by-package in
superpackages, if we have import at all. If we need to use annotations
instead, it is easy to have both types.
As we discussed (and I think you also agreed), we can make the import
dependency to be generic with a name, and the name could be a module
name (or a package name in the context of OSGi interoperability). We'll
only need to have a single import-by-name either in the superpackage or
in the form of annotation.
- Stanley
