Feature Request

The current desktop packaging tasks do not include options for setting up file associations, a particularly valuable feature for desktop apps.

Possible Workaround

The AbstractJPackageTask allows us to add custom args with the freeArgs property, which get passed-through directly to jpackage. So to add our file associations, we should be able to follow the documentation linked above and manually add the args we need.

// build.gradle.kts
plugins {
    kotlin("multiplatform")
    id("org.jetbrains.compose")
}
compose.desktop {
    application {
		...
    }
}

tasks.withType<AbstractJPackageTask>().all {
    // add custom args to jpackage to set up file associations
    freeArgs.add("--file-associations")
    freeArgs.add(project.projectDir.resolve("ext.properties"))
}

macOS Problems

The above workaround does not seem to work on macOS (I have not tried it on other OSs). macOS handles file associations differently than Windows or Linux, and has a particularly verbose "registration" process that involves adding a bunch of additional information to the package's Info.plist file. Normally, jpackage would add all this info to the Info.plist file itself in accordance with the --file-associations property, but the Compose for Desktop Gradle plugin is writing that file itself. This means that even if we add those flags manually using the freeArgs property, the application will still not be registered to open custom file types, because the Compose Gradle plugin is not adding the necessary properties to the plist it writes.

In addition, the CfD plugin adds freeArgs before it configures itself, and it specifies --resource-dir for its own use when writing the Info.plist, so we cannot provide our own resource dir to write the plist by hand ourselves either.

Solution

Rather than writing the Info.plist file within the CfD Gradle plugin, it should let jpackage do it.

Potential Issues

There may already be info CfD is manually adding to Info.plist that jpackage is not adding (which may have been the reason for manually writing it in the first place). Removing the step to manually write the plist may cause issues with some of the existing Gradle plugin properties, and deeper research into customizing jpackage usage or other workarounds may need to be added to fully support them.