Gradle Scripts

Kevin Rushforth kevin.rushforth at
Tue May 27 17:05:29 UTC 2014

I just checked and JavaFX 8u-dev builds fine with JDK 8u5. I suspect you 
have an out-of-date repo.

-- Kevin

Kevin Rushforth wrote:
> Hi Scott,
> I don't think we can use gradle wrapper since it would require 
> checking a gradle jar file into our repo (there is IP / licensing 
> concern with that).
> Regarding your other issues:
> 1) The Mac issue is a known problem that I still plan to address for 
> 8u20:
> 2) In the short term we are unlikely to change our production build to 
> a newer version of gradle, but I know of no reason it won't work with 
> gradle 1.12 (gradle 1.11 is known not to work). Does it build for you 
> with 1.12? I will try it myself.
> 3) The version check should work fine with JDK 8u5. Are you cloning 
> openjfx from the right place? openjfx/8u-dev/rt ? I'm fairly sure this 
> has been tested, but I will double-check.
> 4) Yes, we expect cygwin -- mainly for native but also for some of our 
> legacy any scripts (mostly in closed). We could consider accepting 
> patches that checked whether a windows build was cygwin and allowed it 
> to build at least the java code without requiring Cygwin. Did you want 
> to file a JIRA for this?
> 5) Native compilation for everything except media and wekbit, is on by 
> default, and there is currently no easy way to disable it. This is 
> something Richard had wanted to change back when the gradle build 
> scripts were developed, but was not finished. At the least, a flag to 
> turn off native compilation would be good. Do you want to file a JIRA 
> for this?
> -- Kevin
> Scott Palmer wrote:
>> I know the wiki says only Gradle 1.8 is "guaranteed to work" so I 
>> have to ask:
>> Why not use the Gradle Wrapper to force use of 1.8?
>> Well, I tried tweaking the build scripts to use it myself, running on
>> OS X and found that the scripts appear to be badly broken anyway and
>> they can't even be parsed with later Gradle versions so you can't even
>> run the wrapper task:
>> The error is:
>> Could not find method 'defineProperty() for arguments
>> [MACOSX_MIN_VERSION, 10.7] on root project .....
>> Sure enough the defineProperty method is being called from a different
>> .gradle file than the one in which it is defined, so it is out of
>> scope.  I corrected this locally by changing it to a closure and
>> assigning it to project.ext.defineProperty.  Then I added:
>> task wrapper(type: Wrapper) {
>>   gradleVersion = 1.8'
>> }
>> and was able to get the gradlew script created by running:
>> gradle wrapper
>> So then I tried to build with Gradle 1.8 by running:
>> ./gradlew
>> Then I hit :verifyJava complaining that the build number (13) was too
>> low (< 115)... but I'm building the 8u5 code with the 8u5 release...
>> that seems like a combination that should work.
>> I think everyone (myself included) would be more inclined to help with
>> patches if it wasn't such a pain to build.  I appreciate that prior to
>> the use of Gradle this was likely much worse.  Gradle is a great build
>> system and should be able to make this an even simpler process.
>> On Windows for what I assume are historical reasons, Cygwin is
>> expected.  I'm only trying to build the Java side of things.. not the
>> native DLLs and I don't see Cygwin doing anything of value in the
>> build scripts for that case.  It's mangling paths that don't need to
>> be mangle for example.
>> I think the build scripts could be cleaned up to provide a much
>> smoother build experience for those outside of Oracle.
>> No doubt you guys simply don't have the cycles to burn on fixing build
>> scripts that are currently working for you.. but I suspect it will pay
>> off in the long run.  The current version of Gradle, 1.12, is the last
>> 1.x Gradle release before the 2.x versions appear.  It may make sense
>> to achieve compatibility with it.  Gradle 2.x is expected to break
>> things, but once things are working with 1.12, then you can work on
>> getting rid of the warnings and you will be in a much better position.
>> Cheers,
>> Scott

More information about the openjfx-dev mailing list