hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls.
roman at kennke.org
Tue Dec 6 13:24:54 PST 2011
> > In any case, installing one locally is trivial, this is what we do to build ThingsFX:
> > mvn install:install-file
> > -Dfile=/path/to/javafx-sdk2.0.2-beta/rt/lib/jfxrt.jar
> > -DgroupId=com.oracle.javafx -DartifactId=javafx -Dversion=2.0
> > -Dpackaging=jar
> For JFXtras we do the same (I think we call the artifact javafx-runtime or something), but we also create a jar containing all the DLLs and install that with the same name plus the "windows" classifier. Application.prelaunch unpacks the DLLs to a temp directory and modifies the java-library-path to match. It would be better if the DLL load logic could load directly from the jar.
This should not be difficult to implement (I did that for a project a
while ago) and it helps a lot because if the native lib is embedded in
the JAR it's much easier to use the library because you can copy around
the JAR only and it still works because the lib is loaded as a resource.
Depending on the size of the native lib and requirements regarding
download size, you could even embed all the native libs for different
platforms in the jar and ship only one version to rule them all ;-) It's
a bit more tricky to make it fast because you don't want to unpack this
thing on each launch, but not rocket science either. I have already hit
a couple of instances where my Eclipse had the jfxrt.jar in its
classpath but couldn't find the native lib because jfxrt.jar was not in
its original location.
More information about the openjfx-dev