Setup the Swing client
Move JavaFX template files and add dependencies
Select all files you find in the com.martinandersson.something package in your FXTemplate, and move them to the corresponding package in the SomeApp-app project:
In the dialog box that NetBeans display after this trick, I check the option Move Without Refactoring. When you’re done, you’ll see all hell brake lose in MainFX.java and somethingController.java since some import statements in these files cannot be resolved. Right-click on the SomeApp-app project and select Properties. Click on the Libraries tree node to your left. The tab opened to your right is called Compile. Click on the button labeled Add JAR/Folder. Add the JavaFX Runtime library jfxrt.jar. On my machine, I found the JAR file here:
The Package checkbox is probably checked. But we don’t need to package the JavaFX Runtime library with our application client. If our end user doesn’t already have the JavaFX Runtime library, it will be downloaded automatically when the user launch the application client through Java Web Start. So uncheck the Package checkbox!
Still in the Project Properties dialog, click on Add Project… and add the SomeApp-lib project! This project, or class library, contains the @Remote annotated interface our application client needs to know about.
Don’t leave the Project Properties dialog just yet. When an application client is launched through Java Web Start, GlassFish should force the client to download all the libraries the Application Client Contained needs. What might be due to the packaging trick we’re doing here, that isn’t the case if you would proceed without adding yet another library. Instead your client would have crashed with an exception being thrown:
So click on Add JAR/Folder and browse your way to..
..or whatever is more applicable on your machine. Select the JAR file that begins with something like javax.persistence. On my machine, I found this JAR file:
This library should be packaged together with our application client, thus make sure the Package option is checked. Now it is safe for you to click on all OK buttons you see until you get back to the IDE and hopefully all red lines will disappear. They didn’t? Let me know by commenting on this blog post! Try to find a solution first and then share.
Move and customize the JNLP file
Earlier when you built the FXTemplate Project, NetBeans created a JNLP file we shall include with the application client we intend to package together with our EAR package. Begin by clicking on the Files tab in the NetBeans IDE and get a file based view of your projects. Browse to the FXTemplate > dist folder. If you don’t see the file here, or perhaps you don’t even have a dist folder to begin with, try building the project again.
Move the FXTemplate.jnlp file to SomeApp-app > src > conf. After this operation, NetBeans will begin to include this file in the distributed jar file under a subfolder called META-INF. Rename the file to something more appropriate, say custom.jnlp.
Go back to the projects tab and delete the FXTemplate project. This project should by now be completely empty and of no use to us. You should also be able to see the custom.jnlp file in the projects tab under SomeApp-app > Configuration Files.
The contents in custom.jnlp are mostly complete but we need to fix some things. Open custom.jnlp in your IDE and go to line 2. Change the href attribute to custom.jnlp. Decomment if you will, line 7. Write a title on line 4. On line 14, you will see a reference to FXTemplate.jar. Change that file name to SomeApp-app.jar. Also, since the size attribute is most likely wrong, and the size attribute is optional anyways, just remove the size attribute. Rename the name attribute on line 19 and 22. You might wonder what implications the main-class attribute has on line 22. I haven’t figure that out myself, but it seems to not matter much since the holy Oracle documentation says:
main-classattribute can be omitted if the first JAR file specified in the JNLP file contains a manifest file containing the
Indeed I have with experience proven that the application will work just like we intend for it to work whether we reference the MainFX class or the MainSwing class in this attribute. So I find it convenient to just leave it as is.
Notice how NetBeans produced two XML elements called resources? If you will, you can refactor those into just one. Again my experience taught me there isn’t nothing wrong leaving them duplicated.
When you’re done hacking the file, it should look something like this:
<?xml version="1.0" encoding="utf-8"?> <jnlp spec="1.0" xmlns:jfx="http://javafx.com" href="custom.jnlp"> <information> <title>JavaFXApp</title> <vendor>Martin Andersson</vendor> <description>Sample JavaFX 2.0 application.</description> <!--<offline-allowed/>--> </information> <resources> <jfx:javafx-runtime version="2.2+" href="http://javadl.sun.com/webapps/download/GetFile/javafx-latest/windows-i586/javafx2.jnlp"/> <j2se version="1.6+" href="http://java.sun.com/products/autodl/j2se"/> <jar href="SomeApp-app.jar" download="eager" /> </resources> <security> <all-permissions/> </security> <applet-desc width="800" height="600" main-class="com.javafx.main.NoJavaFXFallback" name="JavaFXApp" > <param name="requiredFXVersion" value="2.2+"/> </applet-desc> <jfx:javafx-desc width="800" height="600" main-class="com.martinandersson.something.MainFX" name="JavaFXApp" /> <update check="always"/> </jnlp>