Hello Karl,
I would prefer to have this as a small project under tools too,
instead of using it as a dynamic system package exporter at runtime.
The impact on (startup) performance might seem little (even on old
hardware) but for certain embedded systems with less processing power
it might still be too much. But that's not the main reason for me to
prefer having it as a tool.
I agree with Richard that the package list will be a static set for a
specific OSGi framework installation. When installing the framework
and choosing the JRE (and probably settting the execution
environment) you determine the environment.
On Jun 10, 2006, at 14:59 , Karl Pauls wrote:
However, I still think the predefined list solution is somewhat to
restrictive. Consider, for example, I want to have the javax.comm
packages. Due to some restrictions (legal and availability) they must
be on the system loader. My Bundle needs them hence, has a hard
dependency on the javax.comm package. What do I do in regard to
shipping to arbitrary platforms? If I include the javax.comm package
in the package property then my bundle gets started regardless of
whether the packages are actually there and if I don't it never will
be started...
I think the solution to this question is simple. If your bundle needs
javax.comm to be available, then it must either import it or include
a private copy. If you decide to import it, someone has to export it
(either the system bundle, or you can choose to do that from a
separate bundle).
There are some other similar scenarios I can see and, yes, one could
work around all of them without including an auto-detect feature in
the framework, however, all workarounds I can think of are somewhat
ugly (due to involving user actions).
Basically you're installing JRE extensions here and you want to
detect them and export the packages that have been installed as
extensions. For this specific scenario your solution does help, if
you restart the OSGi framework after each modification.
Greetings, Marcel
