On 22.08.14 06:45, Ed Merks wrote:
Tom,
Comments below.
On 21/08/2014 10:37 PM, Tom Schindl wrote:
You are right in that it is an install time problem as well - i think
from a p2 point of view tp-resolution & install a fairly equal - i think
it is the same p2-API-call!
Yes, from our work with Oomph I know for a fact that the same underlying
p2 resolution mechanisms are at work.
The problem at runtime is:
a) javafx is not part of any EE so if you have a package import of
javafx OSGi will not wire your bundle because nobody at runtime
exposes a javafx-package, for javax the EE does that
I see what you mean. It seems related to this question
http://stackoverflow.com/questions/16753429/test-apache-felix-with-java-8-and-javafx
where the answer suggests |org.osgi.framework.system.packages.extra |can
play a role. But that seems problematic because it's so global.
For felix this would be enough for Equinox it is not.
Furthermore, I'm not sure one could declare such a thing and not cause
problems trying to run on Java 1.6, which still ought to work. Other
alternatives are also suggested
http://stackoverflow.com/questions/13240822/using-javafx-2-2-in-osgi-bundle,
but I'm sure you've done more research than I!
It all seems inconsistently different from how javax is handled, but
it's clear that javafx is handled differently in terms of bootstrap
visibility for the JRE, so I suppose some inconsistency is unavoidable...
javax is available via BootClassloader
javafx is available via ExtensionClassloader
b) javafx is part of the ExtClasspath but Equinox does NOT look up
classes from there so in case you think you can get away with out
doing any package impports, Equinox will tell you that no javafx
classes are available
Exactly. In fact for Felix you do always need the package imports for
any non-java.* package dependencies, as I found out enabling EMF's core
runtime bundles to work properly as pure Felix bundles during the Luna
release.
Felix is different to Equinox in that it will load classes from the
ExtensionClassloader by default whereas Equinox does not. One has to
reconfigure Equinox to use the ExtensionClassloader.
So why fixing the runtime and tp/install problem differently (if you can
find a solution) if one - the current one - fixes all of them?
Being curious, I used the wonders of open source to look at
http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.javafx.
I see that it's literally creating a mirror image of the package
structure for javafx (among other things, presumably runtime
implementation support packages), and then simply exports those packages
(along with version numbers you've assigned):
http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.javafx/META-INF/MANIFEST.MF
How does this mechanism help the classes actually load at runtime?
Let's look at it in more detail let's say we have 2 bundles:
* org.eclipse.fx.javafx 1.0.0
* my.sample 1.0.0 (import-package javafx)
The classloader of my.sample 1.0.0 looks like this (BL =
BundleClassloader, CL = SimpleClassloader):
By default this would look like this:
o.e.fx.javafx 1.0.0:
--------------------
BL (o.e.fx.javafx-1.0.0.jar)
CL (Boot)
my.sample 1.0.0:
----------------
BL (my.sample-1.0.0.jar)
CL (Boot)
BL (o.e.fx.javafx-1.0.0.jar)
CL (Boot)
This explains why by default no Equinox bundle can load javafx-classes -
the ExtensionClassloader is not in the CL-Hierarchy!
Now org.eclipse.fx.osgi [1] steps in who adds a hook that allows it to
take part of the Classloader construction for any bundle. It only
handles the classloader creation of o.e.fx.javafx (see line 42 in [1])
and now suddenly the Classloader for hierarchy looks like this:
o.e.fx.javafx 1.0.0:
--------------------
BL (o.e.fx.javafx-1.0.0.jar)
CL Ext
CL (Boot)
which would be enough for pure javafx applications but is not enough
when we are in an swt-embedding env so we detect if org.eclipse.swt is
available (see getSWTClassloader in [1]) and then make the classloader
look like this:
o.e.fx.javafx 1.0.0:
--------------------
BL (o.e.fx.javafx-1.0.0.jar)
CL
CL ($java.home/jfxswt.jar)
BL (org.eclipse.swt)
CL Ext
CL (Boot)
Perhaps it's none of my business, but I'm curious... (BTW, I wonder if
package-info.java might be a better placeholder file in this
dummy/mirror structure?)
Right, i fact there's not need to for a dummy at all - this was only to
make PDE happy
I suppose all this means that no bundle with javafx dependencies can
resolve or run without this specific org.eclipse.fx.javafx bundle being
present. Again, it's none of my personal business, but if this is
indeed the only solution, would Orbit be a better host for such a thing?
org.eclipse.fx.javafx and org.eclipse.fx.osgi have to be in your runtime.
Tom
[1]http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.osgi/src/org/eclipse/fx/osgi/fxloader/FXClassLoader.java
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
