Correct options to package dependent classes with jpackage

Question

I'm building an installer on Windows with a few classes in the application jar but with dependencies on logging (logback). This is not a modular application. I'm finding it difficult to get it built properly since the logging dependencies are not being built into the installer. When it runs, cmd.exe tells me that the slf4j classes are not being found.

This is the build command

jpackage --verbose --dest jpk -p ..\.m2\repository\org\slf4j\slf4j-api\1.6.6\slf4j-api-1.6.6.jar;..\.m2\repository\ch\qos\logback\logback-core\1.0.9\logback-core-1.0.9.jar;..\.m2\repository\ch\qos\logback\logback-classic\1.0.9\logback-classic-1.0.9.jar --win-dir-chooser --win-console --input ..\webspeed\target --type msi --main-jar webspeed-1.0-SNAPSHOT.jar --main-class com.technojeeves.webspeed.WebspeedSystray

I'm hoping it's not necessary to have a fat jar as the starting point, since when I tried that after using Maven Shade, I found that jpackage took ages and a massive amount of memory. I couldn't wait any longer and terminated the build.

There are very few examples of jpackage per se, other than simple ones that just echo the Oracle docs. I couldn't find a single one for non-modular with deps.

Answer 1

jpackage runs jlink implicitly for module dependencies but does not seem to include the jars.

For builds with non-module jars you can add each jar under your --input directory parameter as a build step before the jpackage command. Create a staging input directory ..\webspeed\target\jars and copy each of the non-module jars to that staging directory.

After running jpackage and then the installer: check the classpath entries are set by inspecting the yourlaunchername.cfg file. Each launcher cfg should contain an entry which indicates that the classpath is setup with installed copies of each non-module jars.

For example a Windows installer should show:

[Application]
app.classpath=$APPDIR\jars\logback-core-1.0.9.jar
app.classpath=$APPDIR\jars\logback-classic-1.0.9.jar
...

If/as module dependencies don't change much it is usually quicker/easier to pre-prepare a jlink image containing the module images and pass in --runtime-image ${your.jlink}.