RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v5]

John Neffenger jgneff at openjdk.java.net
Sat Sep 18 17:17:05 UTC 2021


On Fri, 17 Sep 2021 23:24:45 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> * The timestamps for all files in the zip archives are set to a hard-coded "1980-02-01", rather than the date and time specified by `SOURCE_DATE_EPOCH`.

That date was chosen by the Gradle project five years ago in the commit ["Add sortedFileOrder and preserveFileTimestamps for archive tasks,"][1] and not changed five months later in the follow-up commit ["Move constants to classes using them."][2] This year, they confirmed the choice by closing the issue ["allow to configure timestamp used for preserveFileTimestamps."][3].

Also see [my comment][4] on the closed issue for more background information.

At this point, it might be safest to go with the five-year-old Gradle default when compared to the alternatives:

1. Invoke the `find` and `touch` command-line tools from Gradle as described on the Reproducible Builds website under the "File modification times" section of the [Archive metadata][5] page.
2. Figure out how to do the equivalent thing in Gradle, perhaps using the `eachFile(closure)` or `eachFile(action)` method of the [`Zip` task][6].
3. Add a post-processing step outside of the Gradle build that runs [`strip-nondeterminism`][7] to normalize the JAR and ZIP archives and then repackages the SDK, JMOD, and Javadoc bundles.

Gradle is our build system. In for a penny, in for a pound?

[1]: https://github.com/gradle/gradle/commit/0209b5dd
[2]: https://github.com/gradle/gradle/commit/8b8daf34
[3]: https://github.com/gradle/gradle/issues/14819
[4]: https://github.com/gradle/gradle/issues/14819#issuecomment-922181921
[5]: https://reproducible-builds.org/docs/archives/
[6]: https://docs.gradle.org/current/dsl/org.gradle.api.tasks.bundling.Zip.html
[7]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism

-------------

PR: https://git.openjdk.java.net/jfx/pull/446


More information about the openjfx-dev mailing list