Gradle build progress

Mario Torre neugens at
Thu Mar 21 01:50:07 PDT 2013

On 03/20/2013 06:55 PM, Richard Bair wrote:
> I think the gradle scripts are now far enough along that you ought to be able to successfully build using them on Mac, Linux, or Windows. At least, I've managed to build on all three platforms but no doubt there are bugs on various platforms due to different configurations.
> To try out the gradle scripts, get the latest graphics repo (,
> cd rt
> gradle -b generator.gradle
> cd ../javafx
> gradle sdk
> You need to have gradle 1.4 installed on your system (I can't use gradlew for now because including a 3rd party library in our source repository requires legal review blah blah). I haven't tried it with other versions of Gradle.
> It should successfully build all Java & native code, and successfully download antlr, junit, and swt dependencies. It requires that artifacts/sdk/rt/lib/ext/jfxrt.jar is present in your root graphics dir just the same as the normal build, OR you can specify -PBINARY_STUB=/path/to/latest/binary/stub/jfxrt.jar
> Please give it a try and let me know if it works for you or if it fails.

Hi Richard,

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'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. 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).

> My next tasks:
> 	- confirm javadoc generation works
> 	- fix any failing tests or configuration that causes tests to fail
> 		- specifically I'm working to get most tests to run reliably in a single VM as they then execute 10x-100x faster
> 	- jardiff the jfxrt.jar normally built with the one built by gradle to look for bugs in the build script
> 	- fix any build issues reported on this thread
> 	- IDE integration
> Then I will work with Mong to get the release engineering requirements in place and get a build setup on hudson and make sure all that is working fine.



More information about the openjfx-dev mailing list