anathema/anathema — pull request #349 by curttasker (2013-07-23 07:08:22+00:00)
Title: Build Cleanup - Using static classpaths rather than dynamic ones.

### Why I'm trying this

I've never been fully convinced that Anathema's dynamic classpath scheme using reflection was the way to go. I figured I'd try to do it "normally", and see what you thought of it.

There's still room for improvement, but I wanted you to see the general direction of my thoughts before I went any farther.

### Build Cleanup

I started by getting rid of all the reflection code we use to build the classpath. This included deleting all of the files in `:Anathema`. I then took `:Platform_Swing/Anathema.java`, moved it to `:Anathema`, and gave it a static main method. This is now the main class of Anathema (which incidentally fixes the menu title issue in #348). I made `:Anathema` depend upon `:Platform_Swing` (it has to now).

`:Anathema/build.gradle` now uses gradle's runtime configurations to build a classpath, which is then put into the manifest.mf file for `:Anathema:jar`. This replaces the old reflection code used to build the classpath dynamically. Note that it is impossible to simply say *include all jar files from this folder* in a manifest file; You must explicitly denote each file.

I also threw in my version of the `copyAllDependencies` code while I was mucking around in here. It seems to work well, but @UrsKR's version worked equally well. (See my email comments on picking one over the other).

### JavaFX Exclusions

With Java 8 and newer, JavaFX classes (`jfxrt.jar`) will be on the default runtime classpath. With Java 1.7.0_02 and higher, `jfxrt.jar` is included as part of the JRE, but you have to manually specify this file on the java runtime classpath.

Currently Anathema bundles this jar inside the JRE for Win/Mac, and we explicitly exclude it being included as part of our runtime dependencies to avoid duplication.

I ran into a minor snag with this method and the new classpaths: There is no way to reference JAVA_HOME inside a manifest file, so you're unable to add `jfxrtr.jar` to the classpath.

This called my attention to an edge case. While we can enforce a minimum JRE version of 1.7 for people running the Zip distribution, we can't enforce 1.7.0_21. Since JavaFX was only included on 1.7.0_06 and newer, its possible for users with older Java 7 installs to attempt to run Anathema through the jar file, and it will fail because there is no `jfxrt.jar` on their system.

The new JavaFX bundling tasks should alleviate this, but until we switch over to it, we need a workaround. I decided on removing our exclusions for `jfxrt.jar` from our dependencies; I compensate by adding the same exclusion to our bundled JREs. Thus we're still only shipping one copy of this jar, its location has just moved.

### Possible problems

I didn't see any immediate issues with our update system, but you'd know better than I would. Because the classpath is now stored in the manifest file of `:Anathema/Anathema.jar`, if any new jar files get added to the project, then this jar file needs to be regenerated and pushed out with the update. This should happen automatically, as the `Anathema.jar` file should be regenerated every time the classpath changes.

### Final Thoughts

Everything seems to be running just as it was before. I didn't run any benchmarks, but I suspect Anathema will launch slightly faster now, due to the lack of dynamic classpath code.

Anyways, let me know what your thoughts are on using this approach.