JavaFX Maven support (was: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls.)

[Daniel Zwolenski]

Maven support would be fantastic. There's two distinct and independent
aspects to this and it's probably worth making these real clear, especially
for the non-maven users:

1. Allow the general public to build their JavaFX applications using Maven.
2. Allow openjfx developers to build the runtime, etc, using Maven

The first one is critical for JFX uptake by Maven users - we Maven users
are so hooked into the whole Maven eco-sphere that if something is not in a
maven repo it virtually doesn't exist for us :)

The second is really a nice to have - so long as the JFX runtime build
process is easy and well documented then it doesn't really matter what
build tool is used (although Maven would make a lot of that modularisation
stuff easier and simplify build scripts significantly).

Regarding the first one (which is my priority), the two things stopping
this from happening right now are:

1. The native DLL loading issue. Maven only really works with the classpath
and not the system path for natives, so we need to do some tricks.
2. The licencing issue - it is currently illegal for anyone other than
Oracle to distribute the runtime, so we can't put the runtime jar or
natives in a public repo yet.

There's no real way to make Java's 'DLL load logic' load directly from a
jar unfortunately (as far as I know). It's the operating system that has to
load the DLLs (or whatever native files are relevant for that OS) and the
OS doesn't understand a 'jar'. One reasonably common trick is the one
described below where the natives are included in the jar and then on
startup, the natives are extracted to a local temporary location, which the
OS is then made aware of. This works but it is a little hacky - the jar is
now more of a delivery mechanism for the natives, rather than just a
resource containing them (e.g. remove the jar and there's no guarantee the
extracted dll's are gone, etc). Given no other option, this is the fallback.

Another option is to keep the natives outside of the jar and have them as a
system path dependency. That's pretty much how it works now, except that
the JFX dll loading code uses a directory relative to the jfxrt.jar
location, which is based on the JFX installation structure (i.e. the
natives are in a 'rt/bin' directory and the rt.jar is in 'rt/lib''). When
we start putting things in Maven it loses this directory structure so this
load code fails to find the natives. I think perhaps if we removed this
relative directory structure then Maven could be made to work by including
the natives in the same dependency as the rt.jar.

There may be other options?

One bigger question this whole topic raises for me though: what exactly is
the JavaFX installer doing? If it's just a case of getting the natives on
the path to make JavaFX work, why do we have to make users (and developers)
go through the whole, do you want to install JavaFX drama? Why can't it
just be another jar on the path of my custom application - a simple
dependency that I manage, much like I manage my log4j, spring, and datafx
dependencies, etc?

And if it turns out the installer does actually need to run, why doesn't it
just put the jfx natives on the system path so that when the runtime starts
up it will always find it, regardless of where that jfxrt.jar is on the
local filesystem?

It would be good to get some insight on the inner workings of all this.


On Wed, Dec 7, 2011 at 8:24 AM, Roman Kennke <roman at kennke.org> wrote:

> Hi,
>
> > > 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.
>
> Cheers, Roman
>
>
>