https://kotlinlang.org logo
Join Slack
Powered by
In desktop Compose 1.11.0-beta02 there are two cop...
# compose-desktop
k
In desktop Compose 1.11.0-beta02 there are two copies of 
runtime-desktop-1.11.0-beta02.jar
(probably the same for other core Compose modules): • 
androidx.compose.runtime/runtime-desktop/1.11.0-beta02/.../runtime-desktop-1.11.0-beta02.jar
• 
org.jetbrains.compose.runtime/runtime-desktop/1.11.0-beta02/.../runtime-desktop-1.11.0-beta02.jar
The first is the "proper" one with all the class files in it. The second is just empty folders with the manifest and license files. Is that expected? New structure of dependencies?
image_Original.jpg
This is the entire contents of the second jar
My specific use case is that I have a custom Gradle task that copies all runtime classpath dependencies into one folder. Then I can run a local shell script pointing the Java runtime at the entire contents of that folder as all dependencies. But now there are two identically named jars, and one of them is essentially empty. Whichever file is copied last "wins".
Wrapping the 
copy
block in 
if (!dep.absolutePath.contains("org.jetbrains.compose.runtime"))
is my current workaround
j
I believe the old coordinates are still being built because it would otherwise break native which hard-codes the fully-qualified klib name https://youtrack.jetbrains.com/issue/KT-60874
The runtime moved to AndroidX in 1.9, but it lacked a dependency constraint to prevent duplicates until 1.10.
k
I didn't see this in 
1.10.2
j
This is the AndroidX versioning, not JetBrains
I suspect JetBrains just didn't update to point at the AndroidX versions until their 1.11 cycle
k
So this is new and intended in desktop / multiplatform 1.11?
Going to be painful for usecases like mine
j
Is there a reason you're not using the Gradle application plugin and 
installDist
?
This is a long-standing Gradle problem but I think it was fixed back in the 7.x or 8.x series
I can't find the issue because GitHub search is terrible
k
For these scripts (taking local screenshots of Aurora skins) there is no need for the overhead of the full packaging. The simple use case here is to be able to get all dependency jars in one place and put them in the classpath of the good old 
java -classpath ... MainClass
invocation.
j
that's what the application plugin is doing (via the distribution plugin)
it copies the jars and writes a shell script with the full classpath
it's not doing "packaging"
My duplicate was closed by their dumb stale bot
k
So the application plugin wouldn't work in this case?
j
No. Same result. It's doing the exact same 
Copy
as you are.
k
I'll keep my workaround for now. Maybe another option is to hash the absolute path of the dependency and then prepend it / append it to the file name when it gets copied
a
@Igor Demin
k
There are two pairs of files that have identical names
j
There are lots more than that, you just aren't using them probably
lifecycle-runtime, savedstate-compose
k
Right, this is only for Aurora
Lifecycle runtime is its own can of worms
image_Original.jpg
Two different versions brought in by one Compose desktop version
j
The versions don't necessarily align across JetBrains and AndroidX
k
Same for 
savedstate-compose-desktop
- 1.3.6 and 1.4.0
And this is from beta 03, with two jars marked as rc01
j
Those are the AndroidX ones
JetBrains chose a single unified version which is at "beta03" for all aritfacts, but the AndroidX ones are all different.
Once JetBrains stops publishing their empty jars those two beta03 ones will disappear.
4 Views
Open in Slack
PreviousNext
Powered by