I've filed: https://javafx-jira.kenai.com/browse/RT-37293
With a couple suggestions for fixes. Scott On Tue, May 27, 2014 at 1:54 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > >> *** I have updated to the 8u5-b13 tag as that is what I was patching. >> Perhaps this is the step that puts things out of date? *** > > > Yes, that would be it, since it would not contain the fix for: > > RT-36163: Cannot build JavaFX using JDK 8u20 or JDK 9 > > (same bug would affect building with 8u5) > > Disabling the min build check will be a fine workaround. > > >> Gradle 1.12 fails to build it. I don't understand how the >> defineProperty() method can possibly work, as it is out of scope from >> windows.gradle and mac.gradle scripts. I encountered this on both >> Windows and Mac. > > > It does look like there are issues in building with 1.12 -- a closed build > falls over and dies even earlier (before buildSrc is compiled). If you would > like to file a JIRA we can look into it for 8u40. It would be great to fix > the scripts so it works with 1.8 and 1.12. > > > -- Kevin > > > Scott Palmer wrote: >> >> I am using a clone of http://hg.openjdk.java.net/openjfx/8u-dev/rt/ >> >> *** I have updated to the 8u5-b13 tag as that is what I was patching. >> Perhaps this is the step that puts things out of date? *** >> If that's the case I can just hack the min build check as I already have. >> >> Gradle 1.12 fails to build it. I don't understand how the >> defineProperty() method can possibly work, as it is out of scope from >> windows.gradle and mac.gradle scripts. I encountered this on both >> Windows and Mac. >> >> Interesting point about checking in gradle-wrapper.jar. I do believe >> it is under the Apache License V2.0... I understand how you must be >> careful. You could probably do something clever to add a small script >> that would download it from gradle.org for setting up the initial >> workspace, rather than checking it in. >> >> I created https://javafx-jira.kenai.com/browse/RT-37290 to cover the >> Cygwin issue. >> >> The wiki needs to be updated as it claims: "Invoking gradle without >> any additional parameters will skip the building of all native code." >> See: >> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest >> >> According to the wiki there already is a flag for controlling the >> build of the native parts: "-PBUILD_NATIVES=true" >> >> I've field: https://javafx-jira.kenai.com/browse/RT-37291 >> >> [Steve's message just came in as I was about to press send, thanks! >> You can update the issue as necessary.] >> >> Cheers, >> >> Scott >> >> On Tue, May 27, 2014 at 1:05 PM, Kevin Rushforth >> <kevin.rushfo...@oracle.com> wrote: >> >>> >>> 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: >>>> https://javafx-jira.kenai.com/browse/RT-34388 >>>> >>>> 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? >>>>> http://www.gradle.org/docs/current/userguide/gradle_wrapper.html >>>>> >>>>> 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 >>>>> >>>>>
