New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JarArchiver lacks Maven Toolchains support #238
Comments
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 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 Does this makes sense? |
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. |
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:
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.
The text was updated successfully, but these errors were encountered: