Add option to keep jpackage temporary directory

[Sebastian (sebkur)]

No description provided.

[sebnuc]

This allows us to specify:

compose.desktop {
    application {
        nativeDistributions {
            keepJPackageTmpDir = true
        }
    }
}

with the result that ./gradlew packageDistributionForCurrentOS will use build/compose/tmp/jpackage/ as the temporary directory used by jpackage which will be kept after the execution of jpackage has finished. This is achieved by passing the --temp argument to jpackage. From the help section of jpackage:

  --temp <directory path>
          Path of a new or empty directory used to create temporary files
          (absolute path or relative to the current directory)
          If specified, the temp dir will not be removed upon the task
          completion and must be removed manually.
          If not specified, a temporary directory will be created and
          removed upon the task completion.

When not specifying that option or passing false, everything will work as before, i.e. a different temporary directory will be used by jpackage and will be deleted when it has finished.

The motivation for this Pull Request is to gain more control over the creation of the platform packages when needed. In particular, in our case, we would like to overcome a bunch of limitations of both the Compose plugin as well as JPackage itself when packaging Windows MSI installers. An example is changing the images used in the installer (#2335), which is possible using JPackage but not using the Compose plugin yet. This could be addressed by exposing more of jpackages functionality using the Compose plugin (#2331 and #2336). There are however also limitations to jpackage itself. The wix toolset is used by jpackage to produce MSI installers on Windows and the options that can be passed to it are very limited. We found for example that we need to set the Application User Model ID (AUMID) on the start menu shortcut file. While wix does support this, jpackage does not and even when making it possible to pass custom resources to jpackage (#2331), this particular behavior cannot be changed on the start menu shortcuts that jpackage configures using wix. Even when disabling the shortcut creation, defining a new one is not possible as the require information needed to define one own's shortcut using wix is not accessible (jpackage assigns random IDs to the files in the wix configuration).

It is however perfectly possible to run wix oneself on the image that jpackage produces in build/compose/tmp/jpackage/images/win-msi.image/$packageName/. Essentially this directory contains directories app and runtime plus ${packageName}.exe and ${packageName}.ico. The MSI installer basically copies those files and directories to the user selected install location and (optionally) performs tasks such as creating desktop and start menu shortcuts. Creating a wix toolchain that achieves this is in the same way that jpackage does is rather straightforward.

I think more generally speaking, having this switch opens up a lot of possibilities in the creation of installers for Windows but also for the customization of created native packages on other platforms. It is very valuable to have jpackage build a JRE runtime for the app and the app image, however the way it configures tools down the line to package this into installable packages is rather limited and probably very difficult to improve as one would need to convince changes in the JDK itself to move forward with this. By moving the actual packaging out of jpackage's scope, it becomes possible to even use a different packaging toolchain such as NSIS. It Could also be possible to create MSIX packages based on this, when finding a way to produce those from a plain set of files that are supposed to be installed by it.

[sebnuc]

I'd also like to add documentation to the Native distributions & local execution guide however I wasn't sure which section to add this to. I was thinking we might need a new section there maybe. But before going on to do this, I was hoping to get some feedback on whether this change will be considered for merging.

[Sebastian (sebkur)]

Oh, looks like this is rather unnecessary. Just found out that I can just add TargetFormat.AppImage to the list of target formats and have the plugin generate the app image at build/compose/binaries/main/app/. That's actually much better.