JDK-8133439 : FX build changes for new version-string in verona
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: build
  • Affected Version: 9-repo-verona
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-08-12
  • Updated: 2016-06-13
  • Resolved: 2015-08-17
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
9Fixed
Related Reports
Relates :  
JDK-8061493 - JEP 223: New Version-String Scheme
Relates :  
JDK-8144490 - Update assemblyIdentity version in javapackager manifest for Verona
Description
See JDK-8061493 for more information on the new version scheme.

This JIRA will track the FX build changes needed for the new version-string in the FX verona sandbox.
Comments
Pushed to verona sandbox: http://hg.openjdk.java.net/openjfx/sandbox-9-verona/rt/rev/4eaacb1abad5
15-09-2015
+1
17-08-2015
@Amy: You are correct that we just use whether we are running via a Hudson job as an indication of a production build versus a developer build, and only include the date in the version string if not doing a production build. Note that this part of the logic isn't a change from what we do today (and have done since FX 2). The only changes are formatting changes to match the new version string spec (using '+' instead of '-b' for build number, ensuring no spaces or other special characters in the date code for developer builds, etc). Both before and after this change we use the presence of the "HUDSON_JOB_NAME" property, which is passed into gradle from the hudson-re-build.sh script, to indicate that it is a production build. It doesn't matter what its value is, nor is the name of the Hudson job ever part of the version string; rather the build logic just uses its existence as a flag to indicate production version internal build. I had thought about changing that -- one thing that comes to mind is that we could use the "CONF==Release" (as opposed to the default "Debug") to indicate a production build -- but it would have been one more change (and an unrelated one at that), so I left that part of the logic alone. Thanks.
15-08-2015
The changes look fine. From VersionInfo.java in rt repo, if getHudsonJobName returns zero length, the version will have time stamp in it. If not, it'll have regular version string. Do I understand it correctly? From the view point of a production build, it means that the build will have the correct build version string if it's built from hudson job. This does not imply the version string has the dependency of the hudon job name. Is hudson job name being used to compute or compare with the programmed version string? Running build in hudson, is used to differentiated the dev or production build (a hudson build). In a hudson build, the hudson job name is irrelevant to the version string. Am I right? Other than my questions above, the changes are good to go.
15-08-2015