Gradle build progress

[Richard Bair]

> I can confirm I have the same problem that Peter has (btw, I tried with Gradle 1.3 and seem to work to the same extent that 1.4 does). I guess the real solution is to open another couple of bits of code ;)

I know it would make this build work SO MUCH EASIER.

I just downloaded JDK b82 and did an open build with no problems. I think maybe there were some interface changes between closed bits and it wouldn't build without the latest closed bits (just released this morning). Can you give it another try?

I confirmed that after copying b82/jre/lib/ext/jfxrt.jar into ../artifacts/sdk/rt/lib/ext I could:

gradle
gradle :javadoc

Sadly, the test are broken due to PGStubScene change sets, I am looking into that now (thankfully PGStubScene is in the open so this shouldn't be a "wait another week" kind of mess).

>> I've also run apps based on the resulting libraries. Note that the JDK 8 builds have jfxrt.jar and associated native libraries on the ext class path, which means when you run an app you will likely run into a mismatch of native libraries or java source files. What I did was to remove jfxrt.jar and the prism, prism-sw, decora-sse, and glass dylibs  *out* of my Java 8 JDK and supplied my gradle-built jfxrt.jar first on the class path followed by the binary stub (old jfxrt.jar) file.
>> 
>> Its a pain in the neck, I know. You can also mess with the ext class path / boot class path settings, but that's a pain too. The joys of JDK development :-/. Open to better suggestions on how to run locally built jfxrt.jar and native libraries against a stock Java 8 without all the muss & fuss.
> 
> I think this will be a major problem for everybody, indeed.
> 
> I believe the sanest thing to do is not ship OpenJFX in the ext directory for OpenJDK, or it will make rebuilding from sources next to impossible in Linux distributions.

Can you explain that a bit more? In the Gradle build I actually have taken care of it because during compilation (of everything including javadocs) I set -Djava.ext.libs= so that it clears JavaFX from the path. That seems to do the trick. The only question I had was about whether that would also handle the loading of native libs properly -- Kevin thinks so but I need to confirm.

> I wish Oracle would follow this advice and remove this library from Java 8, people who really rely on the jar to be in part of the external libraries can put it back there any time (i.e. an installer can be provided that put it back there).

Eeek, installers are evil :-). Anyway, FX will be staying on the class path by default AFAIK.

Thanks!!
Richard