Confused about status of JFX+JRE cobundling

[Daniel Zwolenski]

Just to confirm that what I'm doing it what you expect:

I'm using IntelliJ IDEA and I want to do a maven build with jdk7u6 and use
the co-bundled javafx.

   1. I download and install the new jre7u6 which includes javafx.
   2. I tell IntelliJ to use this build and it picks up JavaFX
   automatically (i.e. it adds jfxrt.jar to the classpath for the jre instance
   because it is in the lib directory).
   3. I write my JFX GUI code
   4. I use the 'maven' panel in IDEA to attempt to build ('clean install').
   5. My build fails with error because jfxrt.jar is not on the maven path

Adding 'jfxrt.jar' to the %CLASSPATH% doesn't help as Maven builds it's own
classpath based on what is in the pom.xml (that's kind of the point of it).

So I have a couple of options:

   1. Add a 'system dependency' (these are generally bad in Maven) to the
   jfxrt.jar in my pom.xml so it gets added to the classpath. I then also have
   to exclude it from my final assembly using extra pom config so it doesn't
   end up in the MSI.

   2. Move the jfxrt.jar in the JRE install into the 'ext' directory so it
   gets included in the classpath

I am currently using option 2 but I feel a little dirty hacking directly
with the JRE install and obviously need to do it manually each time I
upgrade. I also assume your build tools will pick up this JRE, so the fact
that I've messed with it will flow into the MSI, etc?

Is this how you guys seeing it being used? i.e. is the current nastiness
just a side effect of this not-on-classpath requirement thing that I should
just live with and hack around, or am I missing some step that would make
this nicer?

Cheers,
Dan




On Wed, Jun 20, 2012 at 2:52 AM, Scott Kovatch <scott.kovatch at oracle.com>wrote:

> On Jun 19, 2012, at 5:58 AM, Joe McGlynn <joe.mcglynn at oracle.com> wrote:
>
> >
> >
> > --
> >> Am 19.06.12 09:37, schrieb Igor Nekrestyanov:
> >>> On 6/19/12 12:15 AM, Tom Schindl wrote:
> >>>> * the unbalanced decision to not provide SDK-Drops as zips makes
> >>>>  repackaging for different platforms complex
> >>> What other platforms you are referring to? Other Linux distros?
> >>
> >> No I'm talking about windows and mac. Say I'm a win32 user and want to
> >> package an application for users on mac and win32. How would you advise
> >> to do so?
> >>
> >> Answer: Buy a Mac because you don't get access to JavaFX jar and native
> >> libs without out it!
> >
> > We understand this limitation, and it will be addressed as part of how
> JDKs are released in the future.  It's a problem for anyone building Java
> apps, not just FX apps.  There are two aspects to it I think:  First, being
> able to grab native or other platform specific bits to package with your
> app.  Second, being able to create platform-specific artifacts from another
> platform (eg. a .app bundle for Mac when building on Windows).  This spans
> not just operating systems, but chip architectures.
>
> Jumping in here… We aren't doing it yet, but there are plans to make a
> download available with JREs that both FxPackager and the appbundler
> project can use to create an application on any platform. As both of these
> tools expand to support other platforms, that JRE archive will expand to
> include additional redistributable JREs.
>
> Tom, I'm sure you are familiar with the Eclipse platform packs that
> contain things like SWTs for all platforms, Equinox launchers, and so on.
> It's the same idea applied to JREs.
>
> -- Scott K.
>
> ----------------------------------------
> Scott Kovatch
> scott.kovatch at oracle.com
> Santa Clara/Pleasanton, CA
>
>