ascheman commented on PR #508:
URL: https://github.com/apache/maven-jar-plugin/pull/508#issuecomment-5344803684

   @seregamorph @desruisseaux @hboutemy
   
   > what I've noticed is that MANIFEST.MF are now having two entries 
`Manifest-Version: 1.0` / `Created-By: 25.0.3 (Amazon.com Inc.)` while the 
original MANIFEST had only `Manifest-Version: 1.0`
   
   Confirmed, and it is worth pinning down precisely because it is a 
**reproducibility** regression, not just a cosmetic one.
   
   **Root cause.** The JDK `jar` tool stamps its own `Created-By: 
<java.version> (<java.vendor>)` into any manifest that does not already contain 
one — there is no way to suppress it short of `-M/--no-manifest`. Reproduced in 
isolation:
   
   | JDK | `jar --create --manifest=<minimal>` yields |
   |-----|--------------------------------------------|
   | Temurin 17.0.18 | `Created-By: 17.0.18 (Eclipse Adoptium)` |
   | Corretto 21.0.10 | `Created-By: 21.0.10 (Amazon.com Inc.)` |
   
   So the same sources produce **different manifest bytes on different JDK 
distributions** — Corretto's `(Amazon.com Inc.)` matches exactly what you see. 
With `addDefaultEntries=true` this never surfaces, because Maven archiver 
supplies a stable `Created-By` (`Maven JAR Plugin <version>`) and the jar tool 
keeps it. It only bites with `addDefaultEntries=false`, where Maven archiver 
deliberately omits it and the jar tool fills the gap with its JDK-specific 
value.
   
   **The decision (and its alternative).** There are two ways to fix it, and 
they differ in what `addDefaultEntries=false` should mean under the jar tool:
   
   - **(a) Always write a stable, JDK-independent `Created-By`.** Even with 
`addDefaultEntries=false`, have the plugin set `Created-By: Maven JAR Plugin 
<version>` (the same value archiver uses with default entries) *before* handing 
the manifest to the jar tool, so the tool keeps ours. This keeps the artifact 
reproducible across JDK distributions. Trade-off: the manifest is not literally 
the `Manifest-Version`-only one you had — it carries a (JDK-independent) 
`Created-By`.
   - **(b) Truly minimal manifest.** Reproduce the exact pre-4.x output (no 
`Created-By` at all). Since the jar tool cannot be told to omit it, this needs 
either `-M/--no-manifest` with the manifest supplied as a regular entry (I 
verified this yields byte-identical manifests across Temurin and Corretto), or 
a post-generation manifest rewrite.
   
   I went with **(a)** as a candidate on my branch 
[`bugfix/508-preserve-directory-entries`](https://github.com/aschemaven/maven-jar-plugin/tree/bugfix/508-preserve-directory-entries)
 — a small change in `ToolExecutor` plus a `manifest-created-by` integration 
test that fails if the final `Created-By` is the JDK-specific value. 
@desruisseaux, cherry-pick, adapt, or drop as you see fit — you may prefer (b) 
to honor `addDefaultEntries=false` literally.
   
   One nuance for the record: strictly, reproducible builds are defined against 
a *pinned* build environment (the JDK included), so cross-JDK divergence is not 
a definitional violation. But Maven's own convention is deliberately 
JDK-independent manifests (archiver uses `Apache Maven` / `Maven JAR Plugin`, 
never the JDK string), and there are real practical costs to re-introducing the 
coupling — e.g. Docker layer dedup across CI runners on different JDK 
patch/vendor. That is why keeping `Created-By` JDK-independent seems worth it 
either way.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to