I have tried this jpackager a bit. It is working fine packaging a Java modular project. However it fails to package a none modular project. I modified my project and removed the modularization and tried again to see if it would work to package our legacy Java 8 project (though now built with JDK 11 and with dependencies on openjfx 11).
I was under the impression that the jpackager should also work to package non-modular projects. The Gradle distribution task produces an tar archive with all the dependencies and my own JAR, which I am using as input to the jpackager. This produces the RPM for the modular project: sverre@mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib> ~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir --verbose --echo-mode --module-path . --module no.smeaworks.movies/no.smeaworks.movies.MoviesApplication Using the jpackager to package non modular project: sverre@mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT> ~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output outputDir --verbose --echo-mode --class no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar ECHO-MODE: Running [rpmbuild, --version] "Adding modules: [] to runtime image." ECHO-MODE: Running jlink [ --output = /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime --module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods] --add-modules = [] --limit-modules = [] --exclude-files = .*\.diz --strip-native-commands = false ] /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException: jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing for java.base module Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use them to customize package. Exception in thread "main" jdk.packager.internal.PackagerException: Error: Bundler "RPM Bundle" (rpm) failed to produce a bundle. at jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642) at jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582) at jdk.packager/jdk.packager.Main.run(Main.java:71) at jdk.packager/jdk.packager.Main.main(Main.java:47) Is my presumption wrong that it should package also non modular projects, or am I missing some runtime flags to jpackager? Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I reckon that Gluon has yet to modularize SceneBuilder? Can you provide some insight how you use jpackage to build the project? I could not find anything on it in the Gluon SceneBuilder GitHub repository. /Sverre Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos <johan....@gluonhq.com>: > Hi, > > As promised, we looked into an interim solution for the packager-gap. Work > for the new Java Packager (12?) is being done in the OpenJDK sandbox repo. > We backported the required changes to an OpenJDK 11 mirror: > https://github.com/johanvos/openjdk-mobile11/tree/packager > > With this, we created modified OpenJDK 11 builds that contain the packager > (wrapper/exe + module including native library). They can be downloaded and > tested/used at > > http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip > > For Windows, you have to unzip the bundle in the same directory as the JDK, > as the packager wrapper expect to find the java binary at the same level. > > Note that these are not products. We use them internally to create > installers (e.g. we're using them for Scene Builder 11 and that works > fine), and they do what we expect them to do, but there are no guarantees > of course so at least for now I recommend using them in development only > (or even better, look at the changes and contribute to > https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport) > > - Johan >