felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emil Eifrém" <e...@eifrem.com>
Subject Re: Re-wire Case [was; Re; Bundle plugin: Importing packages from non-bundles]
Date Thu, 07 Dec 2006 12:52:20 GMT
On 12/7/06, Niclas Hedhman <niclas@hedhman.org> wrote:
> Well, AFAIU, it seems legal to have Import-Package of classes that are
> available internal to the bundle (see 3.8.4), and still have it resolved even
> if there is no Export-Package in the system.

I read it over last night and came to the conclusion that it
terminates in step 3:

"If the class or resource is in a package that is imported using Import-
Package or was imported dynamically in a previous load, then the
request is delegated to the exporting bundle's class loader; otherwise the
search continues with the next step." (3.8.4, step 3)

I re-read it with fresh(er) eyes and now I think it's ambiguous. It
doesn't explicitly say how to handle Import-Packages that can't be
matched to Export-Packages (I read the "otherwise" clause to be
attached to "if Import-Package" not to "if found(Export-Package)").

I ran a test on Knopflerfish (sorry) and they terminate in 3 (rejects
the bundle with a BundleException because of missing or unresolved
packages). It seems like the reasonable thing to do since it avoids
your indeterministic scenario. Furthermore, it seems more analogous
with (my understanding of) embedded or inlined jars: "Framework, from
this point of view I'm an autonomous bundle. Don't you worry about
these particular dependencies."



View raw message