Re: Rewrite of JAR plugin ready for merge

Hello Sergey

Thanks for the checks

Le 26/08/2026 à 13:07, Sergey Chernov a écrit :

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

I'm not aware of a way to avoid that. Maven 3 and, I presume, Gradle 
write the JAR themselves. This pull request delegates to the `jar` tool, 
and that tool adds "Created-By" itself if we didn't provided some value.


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

This pull request runs `jar --validate` after it has created the JAR 
file (Maven 3 did not). It may contribute to the performance problem you 
observed. Can you try the following modification locally and see if it 
has an impact on the performances? In the `Archive` class at line 548, 
there is a `validate` method. Just replace the method body by an 
unconditional `return false;`. It will disable the second pass with `jar 
--validate`.

If there is still a performance gap even after disabling `jar 
--validate`, can you post the profiler results saying where the code 
spend its time?


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

I have not done the test. But if there is no include/exclude filters, 
the plugin just gives the whole directory to the `jar` tool, and the 
rest depends on that tool.

     Martin