Refactoring JavaFX Builds & Sources

[Scott Palmer]

On Thu, Oct 18, 2012 at 5:11 PM, Richard Bair <richard.bair at oracle.com>wrote:

> OK, so we have the following issues:
>
>         - JavaFX is cobundled with the JRE, but is not on the classpath,
> and thus basically doesn't exist for developers
>                 (that is, they have to manually setup javafx on their
> classpath since the JRE doesn't have it)
>         - Native app bundles require the target OS to be available in
> order to create the bundle (obvious pain ensues)
>         - Having to reinstall the JRE to test the latest build of FX
> stinks (even if it is ultimately deployed with the JRE,
>                 being able to link-to / run JavaFX separately makes
> development easier)
>
> Is that right?


I don't think you are going to avoid the target OS requirement to produce
those native bundles. (I.e. you aren't going to run WiX or Innosetup
without running it on Windows.)  As a developer, you shouldn't be providing
an app specific bundle that you haven't tested anyway, so access to said OS
is implied.  Run VirtualBox if you must, to get access to alternate OS
environments for building and testing.  Or have a build-buddy that runs the
OS if you can't afford the OS license.

The last step isn't a big deal for me.  If JavaFX is just part of the JRE
I'm not sure as a developer that I need anything more than early-access
builds (of the JRE) in order to avoid surprises.

Once JavaFX is on the classpath most issues are solved as far as I'm
concerned.  We might be able to deal with some issues now with an ugly
<system> scope Maven dependency and a check for a minimum JDK version.

I'm already using JavaFX in a local Maven repo with some hackery to augment
the classpath and force the JFX runtime to load from somewhere other than
the Maven cache. One option is java -Xbootclasspath/a: which works for
running in the IDE where it loads classes from build folders instead of
jars.  At runtime our Swing app does ugly classpath hacking to put the
JRE's JavaFX runtime on the class path.. much like what the jfxpackager
stubs must do.  It will be great to get rid of that nasty hacking, but it
works well for now.

Scott