Re: Rewrite of JAR plugin ready for merge

Reproducibility is the next topic (critical). Now let's focus on missing
directory entries.
In the current state the PR breaks spring applications at least (we are
talking about the latest Spring Boot 4.1.0, not some old version), which is
a severe blocker.
And the expectation here is that it should preserve the behaviour by
default. Same config of maven-jar-plugin should produce the same JAR file
entries.

On Tue, Aug 18, 2026 at 5:43 PM Martin Desruisseaux via dev <
[email protected]> wrote:

> 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.
>