Cómo encontrar módulos automáticos con javapackager

Estoy empaquetando una aplicación usando javapackager donde el jar principal es un módulo con un módulo-info.class pero se basa en muchos otros tarros que son tarros antiguos, así que los llamo módulos automáticos en module-info.java. Sin embargo, javapackager queja de no poder encontrarlos. ¿Cómo hago para que encuentre los archivos jar para módulos automáticos?

 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) 

He intentado especificar la ruta del módulo (el primer directorio tiene solo el tarro del módulo principal, el segundo directorio tiene todos los tarros que no son módulos):

 /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 

Entonces, después de más investigaciones, he confirmado la respuesta de nullpointer: los módulos automáticos simplemente no son compatibles debido a su acceso a la ruta de clases, lo que rompe la modularidad de los módulos Java 9. Se pueden encontrar más detalles en esta discusión de hace aproximadamente un año: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008559.html

Entonces, hasta que Oracle y la comunidad de Java decidan cómo lidiar con esto, javapackager en Java 9 no le permitirá usar módulos automáticos. Si agrupa una aplicación que utiliza un módulo, todas sus dependencias también deben ser módulos. Si necesita dependencias que no sean módulos, entonces tiene que hacer que todos sus archivos no sean módulos. Si hace que su (s) contenedor (es) modular (es), entonces tiene que hacer que todas sus dependencias sean modulares, lo que puede ser una gran cantidad de trabajo o no es posible si no posee esas dependencias.

Si hace que todo sea un no-módulo, la desventaja es que no obtiene la ventaja de un tiempo de ejecución más delgado que incluye solo los módulos que necesita. Hay una solución para esto aquí .

Mirando más allá, la excepción parece estar justificada en su implementación sobre los módulos automáticos, pero el mensaje parece disimularse como se indica en BUG # JDK-8189671 .

¡Parece que un complemento informa que un módulo automático se está utilizando como raíz debido a la falta module-info.class recurso module-info.class ! jlink debe detectar el bash de usar el módulo automático como root por adelantado e informar el error claramente.

Por lo tanto, debe especificar el --module-path para modularJars en su lugar.

Nota adicional : las herramientas de empaque de Java ( javapackager ) usan la herramienta jlink para generar un JRE personalizado para la aplicación.