Refactoring JavaFX Builds & Sources

[Richard Bair]

OK, so we have the following issues:

	- JavaFX is cobundled with the JRE, but is not on the classpath, and thus basically doesn't exist for developers
		(that is, they have to manually setup javafx on their classpath since the JRE doesn't have it)
	- Native app bundles require the target OS to be available in order to create the bundle (obvious pain ensues)
	- Having to reinstall the JRE to test the latest build of FX stinks (even if it is ultimately deployed with the JRE,
		being able to link-to / run JavaFX separately makes development easier)

Is that right? I'll probably circle back with you on the native / jar issue in a bit, my head is in another space at the moment (trying to get annotation processor working). These are all definitely issues. Would you be able to check and see what the corresponding issues are in JIRA, or file new issues an let me know? I'm going to wrangle the right people.

Richard

On Oct 18, 2012, at 2:02 PM, Mark Fortner wrote:

> Hi Richard,
> The issue below is about making JavaFX projects build with Maven.  In particular it makes the process of creating a JavaFX project a snap to do by generating the appropriate directory structure, and configuring the POM file to generate the artifacts that people want (like JNLP files, JARs, RPMs, etc).   You could test the archetype using your Ensemble project.  
> 
> Cobundling of JavaFX solves certain problems, but since the source isn't released yet, and since the default build classpath doesn't include JavaFX you still have to do add JavaFX as a dependency.
> 
> 
> >
> > 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?
> 
> 
> Maven repos can include a variety of different artifacts; however, since the non-native code is expecting the native code in the same directory, it's easier to simply bundle a copy of the class jar with the native artifacts.  For example, in my case, I put the dylib files into a jar called jfxrt-mac-2.2.0.jar.  I then installed the jar into my local maven repository.
> 
> 
> 
> > 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.
> 
> 
> Assuming that you don't need the native bits to create platform-specific builds of your app, then we should be OK.  I looked into your Native Packaging tools earlier in the year, it seemed that you needed to be on the platform you were building for. Which was a non-starter for me since I build on a Mac and deploy to both Windows and Mac.
> 
> The only problem that not deploying the latest build would have, would be in cases where you've submitted a bug, somebody posts a fix for it, and you want to verify the fix.  If you use the nightly build, then you should be able to verify that the fix addresses the problem by running your code with the nightly snapshot libraries without having to build JavaFX from source. Often times waiting until an official release occurs, will cause you to miss your own deadline.
> 
> Cheers,
> 
> Mark