Hello Sergey
I think that I see the problem. It you want to try by yourself, you can
build again with `mvn ... -X`. Ignore the flood of logs emitted by
Maven. The interesting part is that you should have a `target/jar.args`
file containing all arguments given to the `jar` command. You can then
reproduce as below:
rm target/*.jar
jar @target/jar.args
You can open `jar.args` in an editor and add/remove/edit arguments until
you get the desired result. I tried on a small project. Notes:
* The Maven JAR Plugin enumerates all files if there are
include/exclude filters, or if reproducible build was requested (for
enforcing a deterministic order). Otherwise, the plugin specifies
only the root directory and the `jar` tool iterates itself over the
entries.
* If `target/jar.args` specifies only the root directory, the
generated JAR contains all directory entries as expected.
* If `target/jar.args` enumerates all files, the generated JAR
contains only those files and is missing the directory entries.
* If `target/jar.args` enumerates both files and directories, the
files are ignored. The directory seems to have precedence: all files
are included regardless the include/exclude filters, and the order
is unspecified.
Can you try the following?
* In `jar.args`, keep only one -C argument followed by the root
directory and remove all other -C arguments (until the end of the file).
* Run `jar @target/jar.args` and check if the result resolve the problem.
If this experiment is positive, it means that we may not be able to
enforce reproducible build with the `jar` tool as it stands today.
However, I would not consider that as a blocking issue, but rather as an
encouragement to provides semantically equivalent builds rather than
bit-to-bit reproducibility.
Martin
Le 18/08/2026 à 16:49, Sergey Chernov a écrit :
I've rechecked, the target problem is fixed indeed. But now I see another
issue.
I've built the JAR and it's not binary equal to the original one.
The Spring Boot application fails to start, while everything looks ok on
the first sight.
I used Claude to binary compare old and new archives and it concluded
interesting:
```
Every class/resource entry matches by name, uncompressed size, and CRC-32.
What differs:
- Directory entries: server3 jars contain them (com/, com/acme/, …);
server2 jars omit them (770 jars).
```
As a result, the spring boot application fails to discover some
componentScan related components, which rely on JAR traversal.
I can do more tests, but I believe this is quite close to being correct
finding, which IMO is severe.
I've rechecked with the master build of maven-jar-plugin, the problem is
not there - so it's new.
