felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Pauls" <karlpa...@gmail.com>
Subject Re: Autodetect JRE packages (was Re: [jira] Closed: (FELIX-78) Modify framework to export proper JRE packages for the execution environment)
Date Sun, 11 Jun 2006 10:50:41 GMT
> I would prefer to have this as a small project under tools too,

No objections. I'll commit something in due course.

> 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.

That's why I did talk about making it an optional feature that _may_
be used but is not the default :-)

> 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.

I disagree. This is a valid point of view but it is not the only one.
The point is that a JRE might change or "be extended" (using the
classpath,  the extension dir, etc.). With a static list  the list has
to be adapted manually - This probably is o.k. most of the time but
I'd like the possibility to just let the framework take care of that.

> 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).

Oh well, the problem with examples always is to find a good one :-).
The issue here is that it is not possible to bundle javax.comm due to
legal/licensing issues plus it needs to be on the bootclasspath. In
other words one can advise the user to install javax.comm in the
bootclasspath but can not bundle it up. That's the hole point.

Again, there are other examples (probably better once too). The
overall question is do we provide an auto detect feature additionally
to a static list or not.

> 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.

Exactly, my solution does help - a static list of packages does not
(in this scenario).

> Greetings, Marcel

I'm fine with committing my stuff to tools. It's down to 0.1-0.3
seconds if nothing changed while still at about 5 seconds on the first
run. If nothing else I'll let it output something that can be used as
the jre-packages property.

Still think it would be a useful optional framework feature...



Karl Pauls

View raw message