Re: Rewrite of JAR plugin ready for merge

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.