Java SE (Java Platform, Standard Edition)

I am (somewhat reluctantly) about to have a stab at putting together the much needed Maven plugin for JavaFX. I could use a little info to help with this, probably from the JavaFX dev team, but if anyone else has thoughts, ideas or wisdom, please chip in! I'd also be interested in a general "show of hands" - who actually wants this and would use it? Is the demand there to warrant the effort?

Maven support for JFX should include the following:
1) The ability to add JavaFX as a dependency to a project (for both compile time and runtime)
2) The ability to do all the packaging stuff currently provided by the JFX ant tasks
3) Silent download and install of the JavaFX SDK for use by the plugin (in much the same way as the GWT maven plugin works with the GWT SDK).

The first two are absolutely required. The last is an ideal case and could be optional (in this case the user would have to manually install the SDK and then point to it in their Maven plugin configuration).

Below are the challenges with each of the above options. I'd really like any input from anyone who has information on the below topics no matter how large or small that information is.


Challenge #1 - Native DLL loading makes it hard to publish JFX as an 'artifact'

Creating an 'artifact' in Maven that other people can use as a 'dependency' is easy. All we do is take the jar (jfxrt.jar) and deploy it to the central maven repository with a well-defined 'groupId' and 'artifactId' and 'version'. Developers could then just add a reference to this and happily compile their apps against this jar. What Maven does, is it downloads the jar from the central repository to a local maven cache directory on the developers machine and then adds this to the compile classpath.

The problem is the native bits. JavaFX has a whole lot of DLLs (for windows) that need to come with the jar. In the JFX installation these are all in the 'bin' directory and the JFX platform is hard-wired to load them from this directory, relative to either the 'system path' or the location of the jfxrt.jar file (which is in the 'lib' directory). Since the jar is now stored in Maven's cache, the DLLs are no longer found. The compile works, but when we run it, it crashes and burns.

Maven will let us deploy DLLs (and other native files) to the central repo as well but to make them platform dependent we have to make a specific artifact for each platform (e.g. a windows one with all the DLLs, a mac one with '.so' files or whatever it is, etc). Since Maven uses an internal directory structure for its local cache (based on groupId and artifactId) that we have no control over, the DLLs will be in that directory structure and never be in a 'bin' directory relative to the jar file (which also can't be in a 'lib' directory).

One option could be for JavaFX to do its DLL loading in a different way. If the DLLs were loaded from the classpath (does anyone know if this is possible, and/or a bad idea?) then Maven can get the DLLs on the classpath. Alternatively, if JFX didn't use a subdirectory for the DLLs and they were just in the same directory as the jfxrt.jar file, then Maven could probably manage that too by making the jar and its DLLs all one artifact (which would then be cached in the same directory).

An even longer shot, could the 'install' of the JFX runtime maybe specify where the DLLs are installed and then the DLL loading could use that location to load them? That way it wouldn't matter if the jar from the Maven cache was used, as the DLL's would still be loaded from the jar's installation location.

Would any of these options be a big change, would this level of change be something the JFX team would even consider just to support Maven, and how long a turn around would we be looking at if it were?

Does anyone have any other thoughts or ideas on how we could get around this issue? Is there any other way to decouple the location of the jar from the location of the native files?


Challenge #2 - Cleanly using the 'ant tasks' from within a Maven plugin

Implementing feature #2 (i.e. doing all the ant build stuff) should actually be pretty easy. The plan would be to just delegate the calls from a jfx-maven-plugin onto the ant tasks. All the parameters available to the ant options could just be exposed as properties of the plugin. I can easily use the ant-javafx.jar included in the JavaFX install from within my plugin. The code in here looks fairly clean and re-usable (i.e. I should be able to call directly onto the classes and methods contained within).

This will save me from having to do a lot of work in this area, and mean that whatever happens in ant, also happens in maven (bugs and all). It also means that if an update is made in the future, the Maven stuff will pick up that update (assuming no API changes, in which case, I'd just have to change the Maven plugin to match).

Does anyone see any problems with this approach? Any suggestions or comments on this?


Challenge #3 - JavaFX gets 'installed'

Unlike most Java libraries, JFX is more than just a jar. Both the Runtime and the SDK have (separate) installers. I have no idea what these installers are actually doing when they run. Do they just copy files into the install directory or are they doing more magical things with the registry, etc? If so, what are these magical things and why are they needed? There is definitely some registry manipulation going on as we've seen from some of the beta uninstall issues. How much of this registry stuff is really needed, could JFX just be a collection of jars and dlls, etc that just get extracted to a directory rather than 'installed'?

I'm also not entirely sure what is in the 'runtime' install vs the 'sdk' install. Why do we need separate installations for this - is it just the packaging and deployment tools that we get extra in the SDK or is there something more fundamental going on here?

In order to do feature #3 and silently download the JFX SDK, I would have to download the SDK files via Java code in my custom jfx maven plugin. I would need to mimic what the JFX SDK installer does. In a perfect world this would just be a case of grabbing a zip of the files needed and unpacking them in the local maven cache somewhere. Is this possible? If all the SDK does is give the developers the packaging tools then possibly, all I need is the ant-javafx.jar file?


Challenge #4 - I don't want to get sued

Currently the JFX runtime has some licencising issues that prevent non-Oracle entities (such as myself) from redistributing it. From previous posts from Richard, this is due to some third party stuff used by JFX and the issue is in the process of being sorted (any updates on this?).

As it stands right now, would I be able to stick any or all of the following files in the central maven repo without getting a call from the Oracle lawyers:
* JFX runtime jar,
* jfx DLLs,
* the whole SDK,
* just the ant-javafx.jar

Assuming the third party licencing issues get sorted, would that answer then change for any of these files? Is the intent such that I will be able to stick any of those things in the central maven repo and distribute them to my hearts content without me, or end users having to physically agree to any licences or T&C or having any other legal issues between myself, Oracle, Apache or anyone else involved?

If the distribution was a problem, would it be possible to look at using the Java.net maven repository (http://maven2-repository.java.net/) to host any or all of these files. Would this help at all with any legal issues (assuming there are any) - as this would then be like Oracle distributing the files, rather than me.


Any and all feeback is appreciated. Help me, help you :)