Refactoring JavaFX Builds & Sources

[Richard Bair]

Hi Mark

> There's probably two overlapping aims here: 1) to build JavaFX itself, and
> 2) to build JavaFX projects (in your case, projects like Ensemble).
> 
> As you pointed out, Maven can be rigid if you want to do something that it
> doesn't normally do.  It's goal is value convention over configuration.
> But you can mix and match Maven and Gradle, or you can write your own Mojo
> to provide any custom functionality (it's similar to writing an Ant Task).
> The nice thing about Maven is that you can use the artifacts with Gradle,
> Ivy and other build tools.  And those tools include plugins that let them
> interoperate with maven builds.
> 
> As I mentioned in this issue: http://javafx-jira.kenai.com/browse/RT-25723
> You can generate project files for most IDEs.

Is this issue related to building JavaFX with Maven or building Maven-based projects with JavaFX? I know both have been talked about on this list before. It looks like this is the latter (building javafx apps using Maven). In the latter case, JavaFX (because it is cobundled with the JRE) should be treated much like a Java version dependency -- ie: if you want to use JavaFX 2.2, them you update your build to use JavaSE 7u7 or whatnot.

However it is true we have ant tasks for doing things like generating co-bundles, JNLP files, etc and those should have Maven counterparts, so that within your normal Maven build you can very easily add support for FX co-bundle creation. I'm not sure what that looks like in terms of code though.

> Most external developers won't really want to build the native bits.  In
> the past I've created jars that include native DLLs, SOs, and added those
> as dependencies.

I did some research into how this is done in Maven but it was hard to follow. Does Maven, Ivy, and Gradle only support jar files in their repos? If it is wrapped in a jar, do I then have to unwrap before creating the final artifacts?

> If you are using Hudson or some other CI tool, it should be able to handle
> nightly builds and publish them to a Maven compliant repo (thus making them
> usable by anyone using Maven, Gradle, or Ivy).  The next time a developer
> builds, it will fetch the latest build including the native bits (assuming
> that they've configured their POMs to depend on the latest SNAPSHOT).
> Hudson can also handle generating the coverage, and test reports for you.

I don't see how putting JavaFX into Maven repos helps though, since it is co-bundled with the JRE and relies on certain versions in the JRE. In the past, JavaFX was a standalone, and so publishing to a Maven repo would make perfect sense. However now that we're cobundled with the JRE, it seems like it doesn't make sense to publish into a repo. One of the reasons we went for co-bundling was a step along the (hopefully) inevitable path to becoming part of the JavaSE spec (in which case we would have to be co-bundled). Also it allows us to take advantage of advances in JavaSE for performance, Swing integration, deployment fixes, etc.

Cheers
Richard