ascheman commented on PR #508: URL: https://github.com/apache/maven-jar-plugin/pull/508#issuecomment-5340038081
> the `jar` tool does not seem to be designed for an explicit enumeration of files to include. It seems to be designed for working on directories only, in which case the entry order may depend on the tool or the platform. @desruisseaux, I dug into this, and I think the directory-based form is the way *out* here rather than a dead end — the tool's directory order is **not** platform-dependent. Since [JDK-8276764](https://bugs.openjdk.org/browse/JDK-8276764) (*"enable deterministic file content ordering for jar and jmod"*, in JDK 17), the `jar` tool **sorts entries by name** when handed a directory, independent of the filesystem's iteration order or file timestamps. Verified empirically — files created in a deliberately non-sorted order, then `jar -C dir .`: * macOS Temurin 17 & 21 and Linux Temurin 17 → **byte-identical, name-sorted** output every time. So handing a directory to the tool gives us **both** reproducible entry order **and** the intermediate directory entries (`com/`, `com/acme/`, …) — the ones @seregamorph reported missing, which break Spring Boot component scanning. Per-file enumeration is exactly what drops those directory entries; the directory form keeps them and lets the tool sort for us. This also sidesteps a post-generation rewrite of the JAR — the directory entries come straight from the tool, so the archive is correct as produced (no second read/rewrite pass, and nothing extra to keep reproducible). To make it concrete, I put together a branch on top of this PR — CI green on JDK 17 + 21 (full `-P run-its`, 3 OSes): **[`aschemaven/maven-jar-plugin` → `bugfix/508-preserve-directory-entries`](https://github.com/aschemaven/maven-jar-plugin/tree/bugfix/508-preserve-directory-entries)** * **Plain JARs** — hand the whole directory to the tool when unfiltered (base, non-modular, no physical `MANIFEST.MF`) instead of enumerating files. Fixes the missing-directory-entries regression. IT: `directory-entries`. * **Non-modular multi-release** — declare resource directories to the tool even in reproducible mode (the JDK 19+ tool sorts each, JDK-8276764), so base and versioned areas keep their directory entries. IT: `directory-entries-mr`. Include/exclude filters and modular archives still fall back to per-file enumeration (they need it); that's documented in the code. It's meant as a starting point — cherry-pick or adapt as you see fit; I didn't want to push commits onto your PR. Happy to open it as a PR against this branch if that's easier to review. And if any genuine `jar`-tool reproducibility gaps remain, @jaikiran's offer to take specifics to core-libs-dev is the right venue — but for entry ordering the tool already does what we need. -- 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]
