Why isn't JavaFX on the jdk1.7.0_u10build12 class path?

[Daniel Zwolenski]

I have added an extra command to my Maven plugin that does this fix for you
(i.e. copies the JAR across).

See: https://github.com/zonski/javafx-maven-plugin

It's still a nasty cludge but at least it is partially hidden for Maven
users.

Note this is only tested on Windows. If anyone runs it on any other
plaforms and has problems, let me know.

Additionally there is a kickstarter project for anyone wanting to use this:
https://github.com/zonski/hello-javafx-maven-example






On Thu, Oct 25, 2012 at 9:46 AM, Scott Palmer <swpalmer at gmail.com> wrote:

> We always install a private JRE for our apps anyway. It will be shared
> among apps from our company only.
>
> But I meant the update would break my build. Running the app. should still
> work. I think we test to see if we can load the Node class and if that
> fails only then attempt to add jfxrt.jar to the classpath by assuming it is
> beside rt.jar (or whatever jar String.class loads from).  Since Node will
> be on the classpath we will skip trying to hack jfxrt.jar onto the
> classpath in the first place so it won't matter that it isn't where we
> expect it.
>
> Though I'm generally disappointed that things will change yet again in
> unexpected ways if jfxrt.jar moves to a new location.
>
> Scott
>
> On 2012-10-24, at 6:02 PM, Daniel Zwolenski <zonski at gmail.com> wrote:
>
> In that case, might be worth highlighting that if you are using any of the
> deployment options that require the JRE to be 'installed' (i.e. *all of
> them* except native), then the JRE will automatically try to upgrade
> itself on your users' machines. Meaning that at any given moment your app
> could just stop working (e.g. due to a change affecting something like your
> workaround below) without you, the developer, doing anything.
>
> I nearly had this happen with a commercial product of mine in a previous
> JRE release but I noticed it (by pure chance) a couple of days before the
> JRE release. I did some (unpaid) late nights to make my code work on both
> versions of the JRE. Now every JRE release there's a chance it could (and
> probably will) break though, which is one reason, among many, why that
> client is considering a rewrite to HTML (cross browser compatibility pales
> in comparison to the sort of risk created by this JRE update).
>
> This is one of the main reasons I would recommend the native installers as
> the only 'safe' option. Since the JRE is bundled into your distro and never
> actually 'installed', you can guarantee control over it. Everything else,
> you are at the mercy of the elements.
>
> This is just another issue that has been (recurringly) discussed on here
> but not seen as important. Best to assume you're on your own for this sort
> of stuff and use extremely defensive strategies in both your code and your
> deployments.
>
>
> On Thu, Oct 25, 2012 at 1:52 AM, Scott Palmer <swpalmer at gmail.com> wrote:
>
>>
>> On 2012-10-24, at 9:56 AM, Kevin Rushforth <kevin.rushforth at oracle.com>
>> wrote:
>>
>> > > I can confirm that simply dragging jfxrt.jar to the ext package works
>> like a charm.
>> >
>> > Current thinking is that putting jfxrt.jar in lib/ext is what we will
>> do to include JavaFX on the default classpath in FX 8 (and possibly 7u12 if
>> no issues arise with this transition).
>> >
>> > -- Kevin
>>
>> Ah.. then that will break my Maven "hack". Since the path to jfxrt.jar
>> will change and Maven will barf when it can't find the system dependency.
>>  I'm glad that I haven't rolled out that hack yet.
>>
>> Scott
>
>
>