Skip to content

Drop Built-Date, Built-JDK, Created-By from plugin manifests#7578

Merged
karianna merged 1 commit into
PCGen:masterfrom
Vest:reproducible-plugin-manifests
Jun 3, 2026
Merged

Drop Built-Date, Built-JDK, Created-By from plugin manifests#7578
karianna merged 1 commit into
PCGen:masterfrom
Vest:reproducible-plugin-manifests

Conversation

@Vest
Copy link
Copy Markdown
Contributor

@Vest Vest commented Jun 2, 2026

Summary

code/gradle/plugins.gradle:30 set three attributes on every plugin jar manifest. The first one, Built-Date: new Date(), was evaluated at configuration time on every Gradle invocation, with two consequences:

  1. Non-reproducible builds. Two consecutive clean builds produced different bytes inside the manifest, so the resulting jar SHAs differed.
  2. Configuration-cache miss. Reading the wall-clock during the configuration phase makes the plugin tasks incompatible with Gradle's configuration cache.

The companion Built-JDK and Created-By attributes are dropped at the same time because they're redundant: nothing in the codebase reads any of the three (grep -rn 'Built-Date|Built-JDK|Created-By' returns only the writer line), and the main pcgen.jar manifest carries no equivalents — the plugin jars were the odd ones out.

If we want truly reproducible builds, that's a larger, project-wide change: it would have to pin archive timestamps (preserveFileTimestamps = false), file ordering (reproducibleFileOrder = true), and the JDK/Gradle versions across environments, applied to all archive tasks. Keeping Built-JDK/Created-By on plugin jars only would be inconsistent — leaking environment info from a subset of artifacts without buying real reproducibility. A future PR pursuing full reproducible builds can apply those settings project-wide and reintroduce diagnostic attributes uniformly across every Java module.

Test plan

  • ./gradlew :jarAllPlugins — all 11 plugin jars build successfully.
  • Inspected plugins/exportplugins.jar manifest — Built-Date, Built-JDK, and Created-By removed; Implementation-Title, Implementation-Version, and Class-Path retained.
  • Reproducibility check: two consecutive clean builds of :jarExportPlugins produce byte-identical jars (same SHA-1: `1b5ed939...`).
  • Build output reports Configuration cache entry stored. for :jarAllPlugins.

`new Date()` was evaluated at configuration time on every Gradle
invocation, so each plugin jar's manifest embedded the build wall-clock.
That made the jars non-deterministic byte-for-byte across builds and
broke Gradle's configuration cache for plugin tasks.

The companion `Built-JDK` and `Created-By` attributes were dropped at
the same time because:

1. Nothing in the codebase reads any of these three attributes
   (`grep -rn 'Built-Date|Built-JDK|Created-By'` returns only the writer
   line). They were inert metadata.
2. The main `pcgen.jar` manifest does not carry equivalents, so the
   plugin jars were the odd ones out.
3. Real reproducibility would also require pinning archive timestamps
   (`preserveFileTimestamps = false`), file ordering
   (`reproducibleFileOrder = true`), and the JDK/Gradle versions across
   environments — for *all* archive tasks in the project, not just the
   plugin jars. Keeping `Built-JDK`/`Created-By` on plugin jars only
   would be inconsistent: it would leak environment info from a subset
   of artifacts without buying real reproducibility. If a future PR
   pursues full reproducible builds, it can apply those settings
   project-wide and re-introduce diagnostic attributes uniformly.

Verified: two clean builds of `:jarExportPlugins` now produce
byte-identical jars; configuration cache stores successfully for
`:jarAllPlugins`.
@Vest Vest force-pushed the reproducible-plugin-manifests branch from 1101dfc to 8b42f9a Compare June 2, 2026 20:15
@Vest Vest changed the title Drop Built-Date from plugin manifests for reproducible builds Drop Built-Date, Built-JDK, Created-By from plugin manifests Jun 2, 2026
@karianna karianna merged commit bd5f4e5 into PCGen:master Jun 3, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants