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

[Igor Nekrestyanov]

>>
>> 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.
There are many reasons to have installer.

To be able to launch JavaFX application embedded in the browser or using 
Webstart we need to have JavaFX aware plugin/deployment stack to be 
registered in the browser.

As of now we expect JavaFX to work on top of JRE6 and therefore we ship 
new version of deployment stack as part of JavaFX.
To register it in the browser/OS on Windows you need to make registry 
changes. This is one big reason to have install JavaFX runtime.

We also assume that JavaFX runtime is shared install per system (or 
eventually per user) and then we want to be able to keep track of what 
users
have installed/use and autoupdate it when important updates are 
available (e.g. security).

We also use the fact that JavaFX runtime is installed to be able to 
autodetect runtime install path when standalone application is being 
launched
and to ensure other requirements are met (e.g. application may require 
specific version of JavaFX to be available or presence of compatible JRE).
IDE like Netbeans can also detect where runtime/sdk is installed and 
validate that libraries used to compile code .

Overall, having installer helps to ensure typical user/developer has 
reasonable environment.
We realize it may be not perfect way for everybody and this does not 
mean other distribution options are not possible. E.g.

    1) Cobundling JavaFX Runtime with the application
        In that case application is responsible to update private copy 
of runtime and there are no detection issues

    2) Installing JavaFX runtime as part of JRE or as JDK8 module

    3) shipping JavaFX SDK as zip or maven module, etc.

I can not tell if Oracle will officially support any of them for 
binaries distributed by Oracle.
Adding new official artifacts contributes to the test/support costs and 
it is not my call anyways
but once JavaFX code is open sourced alternative/additional build 
artifacts can be easily added.

Like Oracle does not provide official JRE/JDK packages tailored for each 
of existing flavors of Linux but distro vendors can create them based on 
OpenJDK if desired.
>> 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?
BTW, having open lookup path for native libraries is generally security 
hole that intruder may use if he finds a way to add file to the 
directory on the path.

-igor