JDK-8131894 : Cleanup build logic for creating FX modules
  • Type: Bug
  • Component: javafx
  • Sub-Component: build
  • Affected Version: 9-repo-jigsaw
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-07-18
  • Updated: 2016-07-15
  • Resolved: 2015-10-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9-repo-jigsawFixed
Related Reports
Blocks :  
Duplicate :  
Relates :  
Relates :  
Description
Need to cleanup the build logic.

1) Fold all of the logic from the jake-build.sh script into build.gradle
2) Cleanup the build logic related to generating the modules and filtering the classes

Comments
I wasn't able to find ant-javafx.jar in 9.0-jigsaw-2015-10-05 as well as recent builds (i. e. b86_2015-11-01-1501_3731.nc). Was it renamed or is it missing?
02-11-2015

http://hg.openjdk.java.net/openjfx/sandbox-9-jake/rt/rev/bac7052d631f
02-10-2015

I have fixes all of the issues reported and have the linux-arm builds working again. Since the changes are minimal, and this is a sandbox, I will push shortly. If anyone spots anything odd in the delta changes between version 3 and 4 let me know. Final webrev: http://cr.openjdk.java.net/~kcr/8131894/webrev.04/ Delta between version 3 and version 4: http://cr.openjdk.java.net/~kcr/8131894/delta.03-04/
02-10-2015

@Vadim: good catch. I will add the logic for JFR, fix the project(fxpackager) typo, and also address the couple issues David raised. Also, if there is an easy fix for the linux-arm issue I will fix that, too (otherwise I'll file a P2 bug to fix it very soon after I push).
02-10-2015

+1 tested on Linux.
02-10-2015

Kevin, I couldn't find the logic from JDK-8131898 in the build.gradle, Probably something along these lines could help (in the buildModulesTask): if (!IS_COMPILE_JFR && project.name.equals("base")) { copy { from srcModuleInfoDir into dstModuleInfoDir filter { line-> line.contains("requires jdk.jfr;") ? "" : line } } } In this line 3225 def tmpModuleProjList = [moduleProjList, project("fxpackager")].flatten() shouldn't "fxpackager" be referred as ":fxpackager" as in everywhere else? Otherwise looks fine, I tested it on windows with both jake and normal 1.9 build
02-10-2015

Please review the changes for the following: http://cr.openjdk.java.net/~kcr/8131894/webrev.03/ This cleans up the build logic as described. The changes are as follows: 1) The jake-build.sh script is gone. Once again, you just need to say "gradle" or "gradle sdk" to build the sdk, which now includes bulding the javafx-exports.zip file for the JDK jake build. 2) The build now performs the following steps to produce the build artifacts: * The classes, resources, and native libraries for each module are assembled into module-* directories that match what we deliver into the JDK. All filtering is done in this step, eliminating the three other places we were doing it. * A new modular-sdk is created under build for assembling all of the modules. The structure of this is identical to what used to be called "module-exports" * The legacy sdk is created from this 3) The legacy sdk directory has been reorganized to match the existing JDK 9 layout where there is no more jre directory (so our equivalent rt dir is gone) and no more ext directory under lib. Most of the changes are related to this. 4) The interesting changes are in: build.gradle buildSrc/*.gradle I have tested it on three desktop platforms Mac, Windows, and Linux. If you have looked at version .02, the changes in .03 are pretty minor. Here are the delta changes from .02 to .03 : http://cr.openjdk.java.net/~kcr/8131894/delta.02-03/ I also discovered a problem with one of the system tests related to the class filtering changes / simplification; the ES2 classes are no longer present in the sdk on Windows by default (we no longer have a separate dev sdk and release sdk), so one of the system tests fails to compile; this test is not ever run anyway, so I will just remove it as part of this fix. I discovered it after generating the webrev and didn't want to regenerate it.
01-10-2015

Note that the class filtering should ensure that the classes delivered for each platform match the current JDK 9 set of classes. For example, we currently are not filtering out platform-specific classes (e.g., we ship both the D3D and ES2 pipeline on all platforms).
21-08-2015