Re: Rewrite of JAR plugin ready for merge

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