Hi, Actually that might just work. Good idea. I'll take a look at it.
Thanks, Plamen Totev On Wed, Dec 20, 2017 at 9:53 PM, Robert Scholte <[email protected]> wrote: > On Wed, 20 Dec 2017 07:40:24 +0100, Plamen Totev <[email protected]> > 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: [email protected] >> For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
