By Janice J. Heiss on Aug 14, 2012
Bien explains the basics:
“LightView uses the HTTP (REST) protocol to communicate with the back-end server. For the realization of back-end communication, an external library—the Jersey client—is used. LightView connects with the back end (LightFish) at startup time, so it is not suitable to lazy-load the Jersey dependencies for optimization purposes. Furthermore, multiple JAR files are hard to handle for standalone applications; you have to set up the class path correctly and keep all the moving parts consistent. The most convenient way to deploy Java (and JavaFX) applications is simply by starting them with java -jar my-killer-app.jar and deploying a single file that contains all the dependencies.”
He shows how the class files are packaged with the javafxpackager, which is shipped with the JavaFX 2 SDK, using the exec-maven-plugin and explains the core tasks achieved by Maven and describes the what javafxpackager does behind the scenes. He then shows how the LightView application operates and interacts with LightFish.
Bien concludes by emphasizing that the richness of JavaFX lies in the fact that it is another Java library. “Because JavaFX is ‘just’ an additional Java library, all of the established build, test, and deployment infrastructure can be reused. You can develop JavaFX applications using any integrated development environment (IDE) you like. And best of all, you can use a single language in a project, from the Java EE back end to the JavaFX front end.”
Check out the article here.