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

[Scott Palmer]

On 2012-10-24, at 3:33 AM, Daniel Zwolenski <zonski at gmail.com> wrote:

> The problem with any discussion on this is there is no good answer. JavaFX has five ways of deploying (regular jar, executable jar, applet, jnlp, native installer) all of them broken or as good as (whether you use Maven, Ant or anything). 
> 
> The way I proposed is definitely not perfect but moves some pain from one spot to the next. Choose your fetish. 
> 
>> I'm no Maven expert (in fact I hate it with a passion - it's fragile half-baked plugins broke the build on me just today)
> 
> I'd hazard a guess you're trying to do something non-standard with it?

Nearly everything is non-standard from Maven's point of view. (E.g. anything with JNI.) But this last fail was because I had a filename that contained an apostrophe and the maven assembly plugin built an invalid command line for the shell.  Worked on Windows, failed on Linux, despite the filename being legal on both platforms.

>> but what I suggested would continue to work without modifications after the proper co-bundling would it not?
> 
> You have introduced extra and unusual config to your POM.

Everything is unusual from Maven's point of view :-).  The mythical "standard" that Maven requires I've only encountered in contrived demos and example code. Not real-world applications of any significant size and complexity. (And yes we are using Gradle to fill in the gaps. But IDE support isn't at a comparable level for Gradle yet.)

> After co-bundling it should all be unnecessary and should be removed. In the alternative approach, the Pom is the same before and after. Choose your poison. 

But that's what I'm saying. If you don't change the POM it continues to work after cobundling. The POM is the same before and after. While it could be cleaned up be removing the "unusual" stuff that isn't a requirement to get it to build.

Anyway .. This Maven stuff is getting off-topic.

<snip>

> This is all a flaw in the current half-hearted co-bundling. Jfx is tied to a jre version, is deployed within a jre install, but isn't available meaning you have to do something awful to make it work at all. Can't understand the logic behind this partial cobundle - better not to have done it at all until it could be done properly. But again that's been raised many times before. 

This is what scares me about what is taking so long to simply put a single jar file on the classpath.  I fear Oracle is going to do something "fancy" and it is going to be another pain in the butt.  I'm hoping it is just a matter of "we aren't allowed to do that without bumping the major version number".  But even so a new VM option -XX+UseJavaFX would work.

Scott