On Wed, 20 Dec 2017 07:40:24 +0100, Plamen Totev
<plamen.iv.to...@gmail.com> wrote:
Hi,
I've started working on implementing support for modular JARs in
Plexus Archiver but as I research the matter I found that they are
more complex than I expected. I've updated the GitHub issue[1] with
the details but I'll post the findings here as well. The modular JAR
files contain not only version and main class but also:
* List of the packages contained - usually populated by the compiler,
but there are some caveats here. The most obvious one is that for jars
created by the Shade Plugin this attribute will almost certainly be
incorrect - the plugin will most likely introduce additional packages
and the list produced by the compiler will be out of date. The other
caveat are the resources - they could be located in packages and
encapsulated the same way as the classes. The jar tools records not
only the class packages but the resource ones too. Packaging resources
together with the classes may result in incorrect module descriptor if
this attribute is not updated.
* The module main class - passed as argument to the jar tool and it
seems that it cannot be set using the compiler.
* The module version - passed as argument to the jar tool. Could be
set using the compiler(again passed as argument) as well.
* Hashes - calculates the hashes of given external modules that depend
on this one. During runtime java checks the recorded hashes against
the resolved module and and if don't match it will fail. The primary
use case is a module A that exports packages to B and C. An easy way
to break the encapsulation of A is to create module named B. To
prevent that you can record the hash of B and C inside A. Then A will
export the packages only to the intended modules. It is used by the
OpenJDK but could be useful for platforms and frameworks as well.
* Module resolution - marks the module to not be resolved by default or
marks it as deprecated or incubating so at run time a warning is
displayed if it is resolved. I don't think you can set it using the
JDK 9 jar tool but it's present in the code. Maybe it will be
implemented in future version of the jar tool.
To me it looks like the packaging of modular JAR file is more complex
than just packing module-info.class file and the jar tool is no longer
just a ZIP program. Something similar is stated in the tool
documentation[2]:
The jar command is a general-purpose archiving and compression tool,
based on the ZIP and ZLIB compression formats.
Initially, the jar command was designed to package Java applets
or applications; however, beginning with JDK 9, users can use the
jar command to create modular JARs.
For transportation and deployment, it’s usually more convenient to
package modules as modular JARs.
While not at all that complex from technical point of view, I don't
think it is worth implementing, and whats more maintaining, all this
functionality. Probably it would be better if the plugins that produce
JAR files use the jar tool, the same way the compiler plugin does not
compile by itself but uses the Java compiler.
What do you think?
Based on this message it seems worth implementing a JarToolArchiver, using
the jar tool via the ToolProvider[1]
I hope it can still be a org.codehaus.plexus.archiver.Archiver, otherwise
I'll contact the openjdk team about the details of the specifications. I
don't think we need them all, good to know the reason for the extra files.
thanks so far,
Robert
[1]
https://docs.oracle.com/javase/9/docs/api/jdk.jartool-summary.html#module.description
[1]
https://github.com/codehaus-plexus/plexus-archiver/issues/69#issuecomment-349095101
[2] https://docs.oracle.com/javase/9/tools/jar.htm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
