Today I rechecked the updated implementation in the PR. Earlier findings were addressed:
- the Spring project is now bootstrapping - the manifest file now is different, but always specifying the same "Created-By: Maven JAR Plugin 4.0.0-beta-2-SNAPSHOT" (not great, not terrible). JFYI: maven 3 and Gradle by default do no specify this manifest attribute at all ( addDefaultEntries=false) Today I checked the plugin performance as well, comparing it to both 3.x and current 4.x master. *Bad news, the PR version of the plugin is approx 2x slower, than the current 4.x master.* For my builds it's 7s vs 15s for approx 1000 executions (each JAR module). Current 4.x master is just a bit slower than the 3.x version. I used own profiler https://github.com/maven-turbo-reactor/maven-timeline-extension but you can see similar report e.g. via https://github.com/takari/maven-timeline One more performance check we need to do - how the new plugin behaves with the immense number of files to be archived. This can be potentially a huge performance issue as well. Did somebody made these tests? On Wed, Aug 19, 2026 at 9:48 AM Sergey Chernov <[email protected]> wrote: > 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. >> >
