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

[Richard Bair]

> 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).

I think #1 is definitely doable, I would be less optimistic about #2 because it introduces a new build time dependency that we've never had before, and if/when we get slurped into the JDK, we'll probably also lose ant and get make, since there is a build team responsible for such things in JDK land.

> 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.

On #2 here, when 2.0.2 ships (any day now), to my understanding, the licensing issue will be fixed. SO that is good at least :-). I'll leave the discussion of #1 up to you and Roman and the experts since I have no idea.

> 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?

A big part of it is the applet. Also, in the near future we'll be co-installed and then co-bundled with Java, so it will be everywhere Java is.

> 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.

I'm not sure of the specifics but these are really good questions that Igor could answer.

Cheers
Richard