Compose Multiplatform 1.11.0 tightened its default ProGuard ruleset so
`proguardReleaseJars` now fails on unresolved references that 1.10.3
tolerated silently. The v1.09.0 release tag-build hit this on every
desktop leg (macOS DMG, Windows MSI, Linux DEB/RPM, Linux AppImage),
which is why only Android APKs and the macOS-arm64 / Linux Amy CLI
bundles made it onto the GitHub release.
Three groups of references were flagged:
- Jackson kotlin-module 2.21.x value-class converters
(`IntValueClassBoxConverter`, `ValueClassKeyDeserializer$*`, …)
invoke `MethodHandle.invokeExact` with polymorphic signatures
ProGuard cannot resolve against the abstract MethodHandle.
- okhttp's optional TLS adapters (`okhttp3.internal.graal.*`,
`BouncyCastle/Conscrypt/OpenJSSEPlatform`) reference classes from
runtime backends that aren't on the desktop classpath; okhttp falls
back to the JDK default in their absence.
- JNA's `com.sun.jna.internal.Cleaner` inner classes touch synthetic
`access$N` accessors that ProGuard's class-member analysis cannot
follow.
Add `desktopApp/compose-rules.pro` with `-dontwarn` rules for each
bucket and wire it through `compose.desktop.application.buildTypes
.release.proguard.configurationFiles`. Verified locally by re-running
`:desktopApp:proguardReleaseJars` (now BUILD SUCCESSFUL) and
`:desktopApp:packageReleaseDeb` (gets past ProGuard; only fails on the
sandbox missing `fakeroot`, which CI installs in the existing
"Install RPM tooling" step).
Claude
ffd64a2e70