JarArchiver lacks Maven Toolchains support

[onkobu]

It could be a bit late or I missed a discussion that took place before 2016. But I assume I found the reason for https://issues.apache.org/jira/browse/MJAR-62 resp. https://issues.apache.org/jira/browse/MJAR-289.

I'd really like to take part in this but maybe found fundamental issues. It'd be great if somebody with insight to the history could read through my lengthy comment in the bug. To sum it up:

• JarArchiver directly controls ZIP-related classes from the JDK/ Classloader running it
• Maven also supports toolchains creating a totally separate execution context
• MavenArchiver (of https://github.com/apache/maven-archiver) relies directly on JarArchiver
• both, MavenArchiver and JarArchiver are put together by maven-jar-plugin based on a map of Archiver instances that luckily may contain something for the key jar or mjar

It seems pretty obvious that a toolchain with a path to another JDK than the one in use to run Maven may ship as many jar commands as it likes. It has zero effect on JarArchiver. In addition the combination of MavenArchiver and JarArchiver is not meant to use an outbound jar command especially not if this determined during runtime (of Maven itself).

I can think of two options: provide a JarArchiver that wraps a jar command supplied during runtime with a default pointing to the current JDKs variant. Or a sidechannel for maven-jar-plugin to switch to a new implementation of creating JARs based on the jar command of the toolchain available.

Whereas the first option requires way more implementation effort and solves all the issues the second fixes class format issues of manifests only in conjunction with toolchains.

[plamentotev]

Hi,

Plexus Archiver does not use the JDK jar tool to create the jar file. While it is possible to use it, actually the jar tool is very basic, Plexus Archiver provides additional functionality - for example it allows reproducible builds. While it is possible to use the jar tool to create the jars I'm not sure it would provide any benefits (I may be forgetting something of course). Maven Archiver sets the value for Build-Jdk so if the value is wrong, it would be best just to modify Maven Archiver to set the correct value.

MJAR-289 affect only modular jar files. Again (as with "plain" jar files) the jar file is created without the jar tool. But because the module descriptor is in the Java class format and not plain text, Plexus Archiver uses the jar tool to modify it. If the JDK version set in the toolchain is newer than the one used to run Maven, then this exception is thrown as the module description is in version that is not supported (newer version) by the jar tool. Here it may make sense to add support for toolchains. If we go this way we should do it similar to how is done by Maven Compiler Plugin and Plexus Compiler. Plexus Compiler supports running any javac executable but the path to the executable is set by Maven Compiler Plugin using the toolchain - Plexus Compiler is not aware of the toolchains. Similarly Plexus Archiver could be modified to run any jar executable but Maven Jar Plugin should set the exact path.

Does this makes sense?

[onkobu]

Sounds like a plan that replaces a surprise with an implementation along a concise concept. At least to stream line javac in use to compile the module descriptor with the packager in need to read it.