Maven + OSGi + Spring + JavaFX (+Ant)

pforhan — Fri, 13 Feb 2009 21:46:50 +0000

We had to go through a number of steps to support the combination of Maven + OSGi + Spring + JavaFX-1.1 in our Swing-based application. This document describes all the steps and technology we’ve gone through to get it working.

! With JavaFX 1.2, some of the steps have changed. I will post a new entry covering the differences shortly.

Build / Compile

We use Maven as our build system, so JavaFX compilation must coexist with these.

Upload Dependencies to a Maven repository

First, we took every single Jar file in the JavaFX SDK 1.1 and uploaded them into Nexus, our development Maven repository. We took all jars from lib/shared and lib/desktop, uploaded them with groupID of javafx, artifactID matching the Jar name, version 1.1.

Building alongside Java code

To combat an explosion of modules, we determined that we wanted to have a src/main/fx source folder that is compiled and used right alongside src/main/java and src/main/resources. Furthermore, the JavaFX code needs to be able to refer to classes and interfaces in the same module as well as in any maven dependencies.

Our first attempt was to use the seemingly perfect fit, the m2-javafxc maven plugin. Early attempts seemed workable, but things started to fall apart and we had to abandon. Here are some of the issues:

m2-javafxc is based on the maven-plexus-compiler. This compiler will only run once per module. So we were unable to have src/main/java and src/main/fx side-by-side
m2-javafxc filters out anything other than .fx files. So we couldn’t have java and fx intermingled inside a single source folder.
Unfortunately, m2-javafxc is supported by only one individual, and barely used by the community. While the codebase is not large or complicated, this does represent a bit of a risk.

Next, we we noticed that the SDK includes an ant task, something easily runnable in maven. So, we built up a working ant script. If you look carefully, you will notice it takes three parameters. These are covered below.

 name="compile-jfx" basedir="." xmlns:artifact="urn:maven-artifact-ant">
 
	 name="compile.jfx" depends="check-if-should-build" if="should-build">
		 id="javafxc.class.path">
			 dir="${localRepo}">
				 name="javafx/**/${javafx.version}/*-${javafx.version}.jar" />
			>
			 path="${compile.classpath}" />
		>
 
		 message="localRepo: ${localRepo}" />
		 message="jfx ver: ${javafx.version}" />
		 name="compiler.class.path" refid="javafxc.class.path" />
 
		 message="jfxc classpath: ${compiler.class.path}" />
 
		
		 dir="target/fxclasses" />
		 dir="target/classes" />
		 dir="target/clover/classes" />
 
		 resource="javafxc-ant-task.properties" classpathref="javafxc.class.path" />
 
		 srcdir="src/main/fx" destdir="target/fxclasses" includes="**/*.fx" compilerclasspath="${compiler.class.path}" />
 
		
		 dir="target/fxclasses" id="fxclasses" />
 
		 todir="target/classes">
			 refid="fxclasses" />
		>
		 todir="target/clover/classes">
			 refid="fxclasses" />
		>
	>
 
	 name="check-if-should-build">
		 file="src/main/fx" property="should-build" />
		 message="should-build: ${should-build}" />
	>
>

To integrate into maven, we use the following snippet. It ties into the standard lifecycle, as you see, and happens just after src/main/java is compiled. It supplies three parameters to the ant script:

compile.classpath — the modules’s dependecy classpath
localRepo — the root of the local repository
javafx.vesion — the version of JavaFX to build with.

The last two parameters are used in the script to build the classpath to insure all the JavaFX libraries are present during compilation.

            >
               >org.apache.maven.plugins>
               >maven-antrun-plugin>
               >1.1>
               >
                   >
                       >ant-process-classes>
                       >compile>
                       >
                           >
                             name="compile.classpath" refid="maven.compile.classpath"/>
                             name="localRepo" value="${settings.localRepository}"/>
                             name="javafx.version" value="${javafx.version}"/>
 
                             antfile="javafxc.build.xml">
                                 name="compile.jfx" />
                            >
                           >
                       >
                       >
                           >run>
                       >
                   >
               >
               >
                    
                    >
                        >javafx>
                        >javafxc>
                        >${javafx.version}>
                    >
                    >
                        >javafx>
                        >javafxrt>
                        >${javafx.version}>
                    >
                    >
                        >javafx>
                        >scenario>
                        >${javafx.version}>
                    >
               >
           >

Working Around Bugs

Ant Mojo

Next, we tried to wrap the above into a Maven plugin via the nifty Ant script-driven Mojo concept. However, I could not specify dependencies as I could with a Java mojo, and I was unable to get maven to pass the compile classpath into the script

maven-antrun-plugin

It turns out, if you have a multimodule project (we do) and you have multiple invocations of maven-antrun-plugin, the classpath gets set once, by the first run. We had the choice of putting every dependency on every antrun, or the light hack of having an empty antrun in the parent project with every dependency specified.

Clover

When doing a build that includes Clover numbers, clover changes the build classpath to include the artifact with the clover classifier instead of the regular one. We were putting our result classes directly into target/classes

javafxc crash

A dependency on org.apache.felix:org.osgi.compendium will cause the javafxc ant task to crash, hard, with a JVM dump. I suspect it is the javax-servlet 1.0.0, but I’m too lazy to prove that.

+- org.apache.felix:org.osgi.compendium:jar:1.2.0:compile
|  +- org.apache.felix:javax.servlet:jar:1.0.0:compile
|  \- org.apache.felix:org.osgi.foundation:jar:1.2.0:compile

OSGi / Runtime

The above gets us to a compiling and building state. However, our target platform is OSGi, specifically the Felix implementation. We need to be able to supply the JavaFX runtime classes to other bundles.

The javafx-runtime bundle

Rather than packaging each SDK jar individually into a bundle, we just dropped all of them into a single mega bundle. The following POM accomplishes this:

  xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    >
        >PT2>
        >org.bjc.es>
        >1.11.0-SNAPSHOT>
    >
 
    >4.0.0>
    >org.bjc.pt2.javafx-runtime>
    >org.bjc.pt2.javafx-runtime>
 
    
    >${packaging}>
 
    >
        >bundle>
        >-100>
    >
 
    >
        This bundle simply wraps the various javafx-compiled jars as a bundle.
    >
    >
        >
          >javafx>
          >decora-d3d>
          >${javafx.version}>
        >
        >
          >javafx>
          >decora-hw>
          >${javafx.version}>
        >
        >
          >javafx>
          >decora-ogl>
          >${javafx.version}>
        >
        >
          >javafx>
          >javafx-swing>
          >${javafx.version}>
        >
        >
          >javafx>
          >javafxc>
          >${javafx.version}>
        >
        
        >
          >javafx>
          >gluegen-rt>
          >${javafx.version}>
        >
        >
          >javafx>
          >scenario>
          >${javafx.version}>
        >
        >
          >javafx>
          >jogl>
          >${javafx.version}>
        >
        >
          >javafx>
          >jmc>
          >${javafx.version}>
        >
        >
          >javafx>
          >javafxgui>
          >${javafx.version}>
        >
        >
          >javafx>
          >javafxrt>
          >${javafx.version}>
        >
    >
    >
        >
            >
                >org.apache.felix>
                >maven-bundle-plugin>
                >true>
                >
                    >
                        >
                            ${pom.artifactId}
                        >
                        
                        
                        >
                            com.sun.imageio.plugins.gif;resolution:=optional,
                            javax.imageio.*,
                            javax.swing.*,
                            javax.sound.*,
                            javax.xml.parsers,
                            javax.media.*;resolution:=optional,
                            javax.script.*;resolution:=optional,
                            netscape.javascript.*;resolution:=optional,
                            sun.*;resolution:=optional,
                            com.sun.javafx.api;resolution:=optional,
                            com.sun.javafx.runtime.adapter;resolution:=optional,
                            org.jdesktop.applet.util;resolution:=optional,
                            org.jdesktop.animation.timing.*;resolution:=optional,
                            org.xml.sax.*;resolution:=optional,
                        >
 
                        >
                            com.sun.gluegen.*,
                            !com.sun.javafx.runtime.adapter,
                            !com.sun.javafx.runtime.liveconnect,
                            !com.sun.javafx.runtime.provider,
                            !com.sun.javafx.api.*,
                            com.sun.javafx.*,
                            com.sun.embeddedswing,
                            com.sun.media.*,
                            com.sun.medialib.*,
                            com.sun.opengl.*,
                            com.sun.scenario.*,
                            com.sun.stylesheet.*,
                            javax.media.opengl.*,
                            org.jdesktop.layout,
                            !javafx.fxunit,
                            javafx.*,
                        >
                    >
                >
            >
        >
    >
>

You can alternately use Eclipse to export a bundle like this, see the post Running a JavaFX script from an OSGi bundle– generally a good article, but slightly skewed from our purpose.

The bundle created above is not quite perfect; some imports marked optional are probably not optional, but are for parts we aren’t using just yet, like sound, or applets. It is missing all the native code shipped with the SDK, which probably has a performance impact. We also haven’t tested a fully-featured screen yet. Finally, there is another problem, which we’ll see in the next section.

Integrating JavaFX into a Swing Application

I can’t create a Scene!

There is a pretty nice article called How to Use JavaFX in Your Swing Application on the main JavaFX blog. It gives details for how to convert a Scene subclass into a JComponent for use in a swing app. The only problem with that: With the javafx-runtime bundle above, I always get a NullPointerException during some StyleSheet intialization. Even when we do it from the command-line, the result is the same. Again, the javafx-runtime bundle is not quite perfect, and I think that this bears that out.

Getting the JComponent

So, we had a workaround: Extend CustomNode, then create a Scene in Java and inject the custom node in. The class below has a field called node, which is of type javafx.scene.Node, set in by Spring (see next section). We steal some of the code from the above link to help with the final extraction. Also note, we had to duplicate SingletonSequence.java in our package, since it is package-protected in the SDK.

        Scene scene = new Scene(true);
 
        Sequence&lt;Node&gt; seq = new SingletonSequence&lt;Node&gt;(TypeInfo.getTypeInfo(Node.class), node);
        scene.get$content().setAsSequenceFromLiteral(seq);
        scene.initialize$();
 
        // stolen from JFXPanel.java by Richard Bair and Jasper Potts:
 
        String helperName = "com.sun.javafx.scene.JSGPanelSceneImpl";
        FXClassType type = FXContext.getInstance().findClass(helperName);
        FXObjectValue panelSceneImpl = type.allocate();
        panelSceneImpl.initVar("scene", FXLocal.getContext().mirrorOf(scene));
        panelSceneImpl.initialize();
 
        FXValue jsgPanelV = type.getVariable("jsgPanel").getValue(panelSceneImpl);
        JComponent jsgPanel = (JComponent) ((FXLocal.ObjectValue) jsgPanelV).asObject()

Working with Spring

The last piece of the puzzle is the ability to allow Spring to create JavaFX instances and set properties on them. Here is an example JavaFX class:

package whatever;
 
import javafx.scene.*;
import javafx.scene.paint.*;
import javafx.scene.shape.*;
import javafx.scene.text.*;
 
public class EDText extends CustomNode {
    var text:String = Dialog.MESSAGE;
 
    override public function create():Node {
        return Group {
            content: [
                Rectangle {
                    width: 300
                    height: 200
                    fill: Color.BLUE
                },
                Text {
                    x: 20
                    y: 20
                    content: bind text
                    fill: Color.WHITE
                }
            ]
        }; // endgroup
    }
 
    function setDisplayString(newValue:String) {
        text = newValue;
    }
}

It has a single operation, setDisplayString(). Then came this Spring config snippet to access it:

     id="edNode" class="org.bjc.pt2.authentication.ui.EDText">
         name="displayString" value="set a value from spring!"/>
    >

… which of course doesn’t work. JavaFX infers that the setter has a return value because none was specified. Spring is looking for public void setDisplayString(String) but finds public string setDisplayString(String) and complains. Minor tweak to the JavaFX code for the function declaration:

 function setDisplayString(newValue:String):Void {

And it’s all happy!

MuddyHorse Farm and Tech » spring