On Jun 7, 2007, at 7:53 PM, Bryan Atsatt wrote:
[snip]
Richard S.Hall wrote:
My question below still stands. In general, it seems to me that
resolution consists of:
1. Selection of candidate module/bundles based on import
declarations.
2. Class space consistency validation (which may narrow the list if
multiple choices, or result in a failure).
I don't understand what possible difference it could make whether we
use
a module name or a package name to select candidates in step 1. Or
even
if some custom code makes that selection (though I'm not a fan of
this
either.)
In general, I can say your two steps above are correct...Felix
actually
has what amounts to a two-pass resolve that does (1) from above in the
first step and (2) from above in the second step. However, it turns
out
that (2) is actually quite difficult and difficult to do in an
efficient way.
Perhaps it is more difficult for the OSGi framework due to some of the
sophistication of its model, e.g., package substitutability,
fragments,
split packages, package-level uses constraints, etc.
All I know is that we are still finding cases that need to be
clarified
in the OSGi framework for this process...
I won't say that I am disagreeing with you...if we can strip away some
of the complexity of the OSGi model, then I am sure you could
implement
a reasonably straightforward resolver.
Right, that is what I'm trying to get at here. I believe *very*
strongly
that import-by-name is a bad idea. Period. It is just plain wrong to do
the equivalent of "import foo.jar". We can do this already, with
manifest Class-Path. Simply layering version support on it does *not*
eliminate jar-hell!
It is far too brittle, raising all kinds of maintenance issues. Under
import-by-name, refactoring *requires* introducing a "facade" module to
avoid breaking importers. And this facade module now becomes *another*
product artifact to be managed: documented, maintained, distributed,
deprecated, and ultimately perhaps removed.
I truly believe that the Java world will be far better served by having
277 support ONLY import-by-package!
But there has been this background fear that import-by-package is
somehow terribly complex. I can certainly believe that the union of all
the OSGi features *does* result in a lot of complexity.
I just think that is almost entirely orthogonal to *this* domain, since
we are not trying to expose all those other features.
Well, you are preaching to the choir with me. I argued long and hard to
keep require-bundle out of OSGi R4 for the same reasons you list above
(I lost that battle). I also encourage everyone who wants to use
require-bundle to read the section in the OSGi spec that lists many of
its limitations and issues (which were extended in OSGi R4.1).
I would also be happy if 277 only supported import by package, but I
stopped arguing for it since it was kiboshed early in the EG
discussions.
That won't necessarily help us in achieving interoperability, though.
Absolutely; regardless of the outcome of the import-by-package issue,
we
still need to deal with exactly how the loaders can share classes and
resources...
So, I guess we are in agreement, even if the rest of the EG isn't. :-)
-> richard
