It looks like implementation("com.halilibo.compose-richtext:richtext-commonmark:0.16.0")
transitively pulls in the linux skiko runtime org.jetbrains.compose.desktop:desktop-jvm-linux-x64:1.2.0
not also on Linux, but also on Windows. I think that's broken. First I thought I had some thing misconfigured, but I can also track this down to the *.module
files published on Central.
richtext-commonmark-0.16.0.module seems to declare a dependency on richtext-commonmark-jvm
:
{
"name": "jvmApiElements-published",
"attributes": {
"org.gradle.category": "library",
"org.gradle.libraryelements": "jar",
"org.gradle.usage": "java-api",
"org.jetbrains.kotlin.platform.type": "jvm"
},
"available-at": {
"url": "../../richtext-commonmark-jvm/0.16.0/richtext-commonmark-jvm-0.16.0.module",
"group": "com.halilibo.compose-richtext",
"module": "richtext-commonmark-jvm",
"version": "0.16.0"
}
},
{
"name": "jvmRuntimeElements-published",
"attributes": {
"org.gradle.category": "library",
"org.gradle.libraryelements": "jar",
"org.gradle.usage": "java-runtime",
"org.jetbrains.kotlin.platform.type": "jvm"
},
"available-at": {
"url": "../../richtext-commonmark-jvm/0.16.0/richtext-commonmark-jvm-0.16.0.module",
"group": "com.halilibo.compose-richtext",
"module": "richtext-commonmark-jvm",
"version": "0.16.0"
}
}
and in turn richtext-commonmark-jvm-0.16.0.module declares a dependency on org.jetbrains.compose.desktop:desktop-jvm-linux-x64:1.2.0
:
{
"group": "org.jetbrains.compose.desktop",
"module": "desktop-jvm-linux-x64",
"version": {
"requires": "1.2.0"
}
},
It's also verifiable on the command line by showing the dependencies using ./gradlew dependencies
where the dependency shows up on Linux and Windows:
…
\--- com.halilibo.compose-richtext:richtext-commonmark:0.16.0
\--- com.halilibo.compose-richtext:richtext-commonmark-jvm:0.16.0
+--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10 -> 1.7.20 (*)
+--- com.halilibo.compose-richtext:richtext-ui:0.16.0
| \--- com.halilibo.compose-richtext:richtext-ui-jvm:0.16.0
| +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.10 -> 1.7.20 (*)
| +--- org.jetbrains.compose.ui:ui-tooling-preview-desktop:1.2.0 -> 1.2.1 (*)
| +--- org.jetbrains.compose.runtime:runtime:1.2.0 -> 1.2.1 (*)
| +--- org.jetbrains.compose.foundation:foundation:1.2.0 -> 1.2.1 (*)
| \--- org.jetbrains.compose.ui:ui-util:1.2.0 -> 1.2.1 (*)
+--- org.jetbrains.compose.desktop:desktop-jvm-linux-x64:1.2.0 <------------ here
| \--- org.jetbrains.compose.desktop:desktop:1.2.0 -> 1.2.1 (*)
…
Here is a minimal example projects that produces the problem: https://github.com/sebkur/test-compose-for-desktop-richtext (it's a simple side by side markdown editor that shows the rendered markdown on the right side next to the source code, see screenshot below)
The program runs fine on Windows, however when producing an uber-jar or msi release, the native libraries are included for both Windows and Linux then on a Windows build. Given the sheer size of the native skiko library, this is rather suboptimal.
$ unzip -l build/compose/jars/Test-linux-x64-1.0.0.jar | grep skiko-
16768000 2022-10-31 19:56 skiko-windows-x64.dll
64 2022-10-31 19:56 skiko-windows-x64.dll.sha256
29463280 2022-09-30 08:56 libskiko-linux-x64.so
64 2022-09-30 08:56 libskiko-linux-x64.so.sha256
That's almost 30mb native code that gets packaged into the windows binaries.
I can work around the issue by excluding the linux runtime:
implementation("com.halilibo.compose-richtext:richtext-commonmark:0.16.0") {
exclude(group = "org.jetbrains.skiko", module = "skiko-awt-runtime-linux-x64")
}