Maven JavaFx native libraries and OSGi

[Daniel Zwolenski]

>> 
>> 
>> 
> Currently the JFXtras workaround extracts to a tempdir, but the better approach would be to load the DLL's as resources directly from the jar. No need to extract then and that also would work fine for runtime.

Unfortunately I don't believe it is physically possible to "load the DLL's as resources directly from the jar". 

Unlike classes, images, property files, etc, which are loaded into the JVM (ie the virtual 'OS'), the dll's need to be loaded by the physical OS (win, osx, linux, etc). The physical OS obviously has no idea how to read a dll from within a jar file. And therein lies the heart of the whole problem. 

I'd love to be wrong on this, so if anyone can contradict this please do!

That leaves two options that I can see: extracting it from the jar on first run, or delivering it outside of the jar as another top level file. 

The extraction will solve the maven problem but is a little clunky for other usages. It's not so bad as to be unusable though and in my mind is our best viable hack. Would be good if could just be a special maven dependency, like jfx-prelauncher that is separate to the jfx runtime. Could your code be made to work that way do you think? Otherwise perhaps the maven version of the runtime is 'special' and has the prelauncher in it, unlike the normal distro?

The other alternatives I can think of are:

1) Change the jfx code to tell windows to load the dlls from the same dir the jfxrt.jar is in, instead of the relative 'bin' dir it uses currently when telling windows to load the dlls (it could check the normal spot first to not break current code). 

By chance Maven does allow you to put more than one file in for an asset (I'm not sure it is meant for this purpose, but better not to look a gift horse in the mouth), so this could be a do-able option. I think we would either have to deploy the jfxrt.jar once for each platform along with it's natives (ie one artifact for each platform, each containing the jar and relevant binaries) or we would need to bundle all the native binaries for all platforms into one single artifact with the jar. I _think_ either of those options will work. 

This requires a code change from the JFX guys though and as yet I've not had a response on whether they would be willing to do this. (was that nudge unsubtle enough ;) )

2) have a jfx maven plugin that has a jfx:run command. Similar to tomcat:run or gwt:run. This could do anything - put dlls on the path, even download the sdk and add the jar from there to the run classpath, etc. But it is clunky. IDE's probably won't like it and its a lot more pain for developers - and it just shouldn't be needed (tomcat and gwt are platforms/servers so they can justify needing to be run in a special way, jfx can't).  

Co-bundling jfx+jre will be an interesting addition to this whole problem. Where will the dlls live then and will that mean just cause I have java installed, I'll have the jfxrt.jar automatically on my classpath and it will then have access to the dlls? If so all of this will be academic, we won't need a maven dependency, anymore than we need one for java.util or java.swing, etc. Can anyone elaborate on this and also the expected timeframe for co-bundling?




> 
>>