This content has been marked as final. Show 39 replies
Nice hack, mate.
I tried ( -XX:+EnableJavaFX ) with the Maven exec-plugin, building on a shade-plugin generated jar. It runs the application main, loads a Spring context, and quietly exits. The Stage (.show()) is not displayed.
I attempted to run the javaxpackager Ant task within the Maven pom.xml, but the shade-plugin complains about the fx: xml namespace. I tried many Maven life cycles, but to no avail. Do I need to master the Ant usage of javafxpackager and give up the awesome shade-plugin? I should hope not.
Using build 1.7.0_06-ea-b20.
This just in: I forgot to add this single line of code: launch(args); within the main method ( after the Spring context loading ). The stage is now properly displayed. No Ant task required!
Yet I had to add a local Maven dependency as follows (for OSX):
mvn install:install-file -Dfile="/Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home/jre/lib/jfxrt.jar" -DgroupId=com.oracle.javafx -DartifactId=javafx -Dversion=2.2 -Dpackaging=jar
A mvn clean: install won't work without it, at least for now until the classpath issue is resolved. Perhaps, Oracle can work on this a bit.;)
Sorry for such a long post. Hopefully, others can learn from my mistakes.
Edited by: javawerks on Jul 19, 2012 5:08 PM
Edited by: javawerks on Jul 19, 2012 8:47 PM
When you're desperate, you will try anything. And I was desperate.;) But it did occur to me that someone else suggested the -XX:+EnableJavaFX earlier in the thread. Yet I had no time to check. It, of course, thankfully works without 'said' command line argument.
Edited by: javawerks on Jul 19, 2012 8:07 PM
I get the same error when using jdk 7u7 on windows7.
C:\dev>javafxpackager.exe -createjar -appclass mypackage.App -srcdir target/classes -outfile myjar
Error: jfxrt.jar needs to be on classpath for -createbss and for -createJar without -nocss2bin
For building my project i use maven. Therefore i need to add the classes build from the javafxpackager.
Adding -classpath "C:\Program Files\Java\jdk1.7.0_07\jre\lib\jfxrt.jar" to the javafxpackager command does not help. I removed all other java installations from my system.
How did you fix that problem? Where could the failure be?
Edited by: Phil on 10.09.2012 03:44
Just adding a link to this thread to the actual jdk enhancement request to get jfxrt.jar on the boot classpath, so that any unfortunate who stumbles across this thread can track the resolution:
Edited by: jsmith on Jan 4, 2013 2:31 PM
The above issue tracker bug_id has been deprecated, the new ones to track are:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003171 "Need to move jfxrt.jar from lib/ to lib/ext/"
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003172 "Need to move jfxrt.jar from lib/ to lib/ext/"
8003171 is to make this work in jdk8
8003172 is to make this work in jdk7u12
Just wanted to add my concerns about this not being fixed allready, at least on the windows platform. We now are at u9 and neither does it look like an XX option is near nor a real integration of jfxrt.jar as default is happening.
We were considering starting op with javafx components in our existing swing app, but the ant script/packaging tools are just not an option for os at all. Embedding the jar and libs could work but we arent all that keen on this as this isnt a library but a part of the JDK/JRE.
It would be very very nice to get some indication of how this is going and what plans are being made (also if none are being made). Just saying nothing shouldnt be an option. I really hope someone can give some real updates on this.
jfxrt.jar will be in the boot classpath for jre8. It might also go into the boot classpath for jre7uN where N is a number greater than 9. Track the jre issue report I linked earlier to see progress.
I don't believe the XX option discussed in this thread will be implemented, instead JavaFX will probably just end up on a default boot classpath for jre8, which would make an XX option for this largely redundant.
I think the current plan is to place jfxrt.jar in the jre lib/ext directory rather than the jre lib directory - this puts the JavaFX system on the boot class path. You could try this with the jre for your Swing app and see if it works for you. Or you can invoke java using java -classpath <path to jfxrt.jar> when launching your app.
Using the JavaFX packaging tools for packaging apps containing JavaFX is recommended (http://docs.oracle.com/javafx/2/deployment/deploy_swing_apps.htm) - in which case the jfxrt.jar location doesn't matter that much.
I've created a JavaFX Maven Plugin: https://github.com/zonski/javafx-maven-plugin/wiki
It includes a command for fixing the classpath for your JDK (it copies the jxfrt.jar to the ext directory as per jsmith's comment) and then provides packaging goals for building distributables that generally don't need a fix on the actual users systems (i.e. inline with what the JFX packaging tools do).
Blog post on it here: http://www.zenjava.com/2012/11/24/from-zero-to-javafx-in-5-minutes/
jsmith wrote:Using the JavaFX packaging tools for packaging apps containing JavaFX is recommended (http://docs.oracle.com/javafx/2/deployment/deploy_swing_apps.htm) - in which case the jfxrt.jar location doesn't matter that much.Gradle makes this fairly easy. You can replace the logic for the built in JAR creation task and defer to the JavaFX packaging tools instead. I've written a simple example that gets things to the point of creating an executable JAR:
I got the basic idea from this guy:
Fixed links. The built in link option doesn't seem to work.