如何使用javapackager查找自动模块 [英] How to find automatic modules with javapackager

问题描述

我正在使用 javapackager 捆绑一个应用程序，其中主jar是一个带有module-info.class的模块，但它依赖于许多其他普通旧jar的jar，所以我把它们称为module-info.java中的自动模块。但是， javapackager 抱怨无法找到它们。如何让它找到自动模块的jar文件？

I am bundling an app using javapackager wherein the main jar is a module with a module-info.class but it relies on many other jars that are plain old jars, so I call them out as automatic modules in module-info.java. However, javapackager complains about not being able to find them. How do I make it find the jar files for automatic modules?

Exception: jdk.tools.jlink.plugin.PluginException: java.lang.module.FindException: Module rcf not found, required by com.username.commander.ui
Exception in thread "main" com.sun.javafx.tools.packager.PackagerException: Error: Bundler "Mac Application Image" (mac.app) failed to produce a bundle.
    at jdk.packager/com.sun.javafx.tools.packager.PackagerLib.generateNativeBundles(PackagerLib.java:374)
    at jdk.packager/com.sun.javafx.tools.packager.PackagerLib.generateDeploymentPackages(PackagerLib.java:348)
    at jdk.packager/com.sun.javafx.tools.packager.Main.main(Main.java:496)

我试过指定模块路径（第一个dir只有主模块jar，第二个dir有所有非模块jar）：

I have tried specifying the module path (first dir has just the main module jar, second dir has all the non-module jars):

/Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home/bin/javapackager -deploy -native image \
-name Commander -title Commander -vendor "username" \
--module-path /Users/username/Dropbox/coding/commander/Commander-java/moduleJars:/Users/username/Dropbox/coding/commander/Commander-java/packageJars \
--module com.username.commander.ui/com.username.commander.ui.AppWindow \
-srcdir /Users/username/Dropbox/coding/commander/Commander-java/packageJars \
-outdir /Users/username/Dropbox/coding/commander/Commander-java/target \
-outfile Commander \
-Bruntime=target/jre-9.0.1 -Bicon=src/main/resources/icons/commander.icns \
-BappVersion=1.0 \
-Bmac.CFBundleIdentifier=com.username.Commander \
--add-modules java.base,java.desktop,java.naming,java.sql,java.xml,java.logging,java.management,java.scripting,java.compiler,java.rmi,java.activation \
--limit-modules java.base,java.desktop,java.naming,java.sql,java.xml,java.logging,java.management,java.scripting,java.compiler,java.rmi,java.activation \
-nosign -v

推荐答案

经过更多的研究，我确认了nullpointer的答案：由于访问类路径，因此根本不支持自动模块，这打破了Java 9模块的模块化。大约一年前的讨论中可以找到更多细节： http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008559.html

So after more research I've confirmed nullpointer's answer: automatic modules are simply not supported due to their access to the class path, which breaks the modularity of Java 9 modules. More details can be found in this discussion from about a year ago: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008559.html

所以直到Oracle和Java社区决定如何处理这个问题，Java 9中的 javapackager 不允许你使用自动模块。如果捆绑使用模块的应用程序，则所有依赖项也必须是模块。如果您需要非模块依赖项，那么您必须使所有jar非模块。如果你确实使你的jar模块化，那么你必须使你的所有依赖模块化，如果你不拥有这些依赖，这可能是很多工作或不可能。

So until Oracle and the Java community decide how to deal with this, javapackager in Java 9won't let you use automatic modules. If you bundle an app that uses a module, all your dependencies must be modules as well. If you require non-module dependencies, then you have to make all your jars non-modules. If you do make your jar(s) modular, then you have to make all your dependencies modular, which can be a lot of work or not possible if you don't own those dependencies.

如果你把所有东西都变成非模块，那么当然缺点是你没有得到更简洁的运行时的优势，只包括你需要的模块。这个在这里添加有一个解决方法。

If you make everything a non-module, the downside of course is that you don't get the advantage of a slimmer runtime that includes only the modules that you need. There is a workaround for this here.

这篇关于如何使用javapackager查找自动模块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！