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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
