Hello Mathis Replying to only a small part:
Le 17/10/2026 à 13:26, Matthias Bünger a écrit :
With the current discussion about copying archiver code into the jar plugin to remove its depenency makes we also curious. As already mentioned in the discussion I'm not sure that it brings a benefit that the jar plugin will behave differnt in terms of archiving in the future than all other archiving plugins. So we might want to (I guess this was done in the past and there reasons to not do it) to have a more dynamic archiving plugin which can handle also ejbs (yes they are still used in slow moving enterprises and EJB is still an optional spec of Jakarta EE), ears, wars and all the others.
I think that it was the original view. But rewriting the JAR plugin for delegating to the JDK's `jar` tool instead of creating the JAR file ourselves changed the situation. After this rewrite, the Maven JAR Plugin became very specialized to the `jar` tool, since its main work is now to provide options for that specific tool. There is not many things left that are neutral enough for being shared with other archive formats, unless the other formats are very similar to JAR (including almost identical options).
The Archiver code which is copied into the JAR plugin is only a small part, because most of Archiver work is handled by the jar tool. The only remaining thing to copy is the manifest configuration in the POM, and the code that produces a MANIFEST.MF file from that configuration. For making useful the sharing of this code with other archive formats, the other formats would need to have a MANIFEST.MF file with the same information. I doubt that this is the case (I would expect the manifests to have some differences significant enough for deserving their own code). If nevertheless it really happens, waiting for this case to happen will give us a use case, which would help us to design the shared code.
Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
