Using the jpackager

[Rachel Greenham]

FWIW what I'm doing to build a windows app for jpackager, in terms of 
gradle tasks, that isn't modular. I hope this cleans up over time, but 
this is the final result of having just got the damn thing to work! :-)

I think *eventually* we'll have a single call to jpackager do the whole 
lot. But I think we're not there yet, so it's split out into separate 
steps. You *will* need to make changes for your own context:

Build the JRE needed using JLink, supplying the needed modules. The 
JLink task referenced is actually written in Java and wraps 
ToolProvider, but it's pretty trivial and could almost-more-easily be 
done with an Exec. NB: The JLink task as written puts it in a "java" 
subdirectory of the given destinationDir.

     task buildAdminJre(type: JLink) {
         description 'Build the Client JRE for ' + nativeOsName
         destinationDir 
rootProject.file("deploy/bindist/"+requiredJava.merusNativeAdminJreName)
         modules = [
             'java.base',
             'java.desktop',
             'java.xml',
             'java.logging'
         ]
         bindServices false
         modulePath = 
[System.properties.getProperty('java.home')+File.separatorChar+'jmods']
         noHeaderFiles true
         noManPages true
         stripDebug true
     }

Have the jar task build the application as normal. Here's mine as an 
example. The important part is, you don't need to build a single fat 
jar, but you can include the dependent jars with the Class-Path line 
below. Mine isn't a JavaFX app, so I don't know what it does now wrt 
pulling in the openjfx jars here, or whether you add them as modules to 
the jlink task above. I expect the former would be preferable.

     /*
     Basic non-fat jar.
     */
     jar {
         manifest {
             attributes(
                 'Product-Name': applicationName,
                 'Main-Class': mainClassName,
                 'Package-Title': project.group,
                 'Package-Vendor': vendor,
                 'Package-Version': adminVersion,
                 'Permissions': "all-permissions",
                 'Class-Path': 
configurations.runtimeClasspath.files.collect { it.getName() }.join(' ')
             )
         }
         archiveName = 'adm.jar'
     }


Build the application image. This should be mostly platform independent. 
(I think the only thing stopping it being is probably the .ico file for 
the icon.) Note I'm supplying as --input the lib dir from the target 
built by the standard gradle installDist task, so it contains the 
dependencies as well. adm.jar's manifest lists these as dependencies in 
Class-Path as per above. The JRE is supplied in the --runtime-image 
parameter.

     task createImage(type: Exec) {
         description 'Build the App Image for this platform using jpackager'
         dependsOn installDist
         dependsOn buildAdminJre
         def imageDir = "$buildDir/image"
         outputs.dir new File(imageDir,applicationName)
         commandLine 'jpackager', 'create-image',
             '--verbose',
             '--version',adminVersion,
             '--input', new 
File(installDist.outputs.files.singleFile,"lib"),
             '--output',imageDir,
             '--name',applicationName,
             '--description','<DESCRIPTION>',
             '--main-jar','adm.jar',
             '--class',mainClassName,
             '--icon','src/main/files/app-icon.ico',
             '--runtime-image',new 
File(buildAdminJre.outputs.files.singleFile,"java"),
             '--vendor',vendor
     }

You'll now have the application image suitable for your platform. I've 
only tried this on Windows so far.

Note: My app has a space in the applicationName value. This breaks at 
the moment. The following is a workaround task, split out for easy 
removal later when I'm sure it won't be necessary any more:

     task fixWindowsImage(type: Copy) {
         /*
         This task creates a copy of the image created by createImage task
         and fixes it up for using as the source of a Windows Installer.
         As of first writing, what this means is renaming a couple of files,
         because create-image crushes out spaces in the application name but
         we want them in, we have to rename the generated .exe and .cfg 
files
         to have that space again.
         Then msiInstaller will work to actually create the shortcut and
         start menu items.
         */
         dependsOn createImage
         from createImage.outputs.files.singleFile
         into "$buildDir/fixedImage/$applicationName"
         rename ("<NAME-WITHOUT-SPACES>.exe", applicationName+".exe")
         rename ("<NAME-WITHOUT-SPACES>.cfg", applicationName+".cfg")
     }

Then, as a separate stage, run the bit that puts it into an installer. 
So here the input supplied in --app-image is the complete application 
image as already created and fixed by the above tasks.

     task msiInstaller(type: Exec) {
         /*
         see fixWindowsImage for a necessary fix to the created application
         image to allow shortcut and startmenu items to work.
         */
         description 'Build the Windows 64-bit MSI installer using 
jpackager'
         doFirst {
             /*
             For no reason I can discern, this task stopped working
             (did nothing, as if not called) until I added this 
doFirst{} block
             */
             println description
         }
         dependsOn fixWindowsImage
         def msiDir = "$buildDir/msi"
         def msiName = applicationName+'-'+adminVersion+'.msi'
         outputs.file new File(msiDir, msiName)
         commandLine 'jpackager', 'create-installer', 'msi',
             '--verbose',
             '--version',adminVersion,
             '--app-image',fixWindowsImage.outputs.files.singleFile,
             '--output', msiDir,
             '--name',applicationName,
             '--description','<DESCRIPTION>',
             '--icon','src/main/files/app-icon.ico',
             '--win-per-user-install',
             '--win-shortcut',
             '--win-menu',
             '--win-menu-group','<SUBMENU-NAME>',
             '--win-upgrade-uuid','<UUID>'
     }

Left for your own amusement, code-signing! (Off-Topic here although 
arguably jpackager could include that too.)

-- 
Rachel

On 09/11/2018 14:04, Lennart Börjeson wrote:
> I've been trying to understand how to use the jpackager, but I'm stumped.
>
> I have for a long been using the now defunct gradle-javafx plugin, so I've never really used the old javapackager either, only indirectly through gradle.
>
> So I'm maybe asking terribly noob questions, but here goes:
>
> Let's say I have a non-modular application packaged as an executable jar, i.e. a GUI I can launch with the "java -jar" command: How can I package this as a native application/dmg with jpackager?
>
> On a more general note: What's the required layout/contents of the "input directory"?
>
>
> Best regards,
>
> /Lennart Börjeson