https://kotlinlang.org logo
Join Slack
Powered by
There is an interesting situation. I'm working on ...
# compose-desktop
a
There is an interesting situation. I'm working on a library that uses both Jetpack and JetBrains Compose. There are two separate modules for each Compose variant. JetBrains Compose releases are a bit ahead of Jetpack Compose. The latest JetBrains Compose version 
0.2.0-build132
requires Kotlin 1.4.20, whereas Jetpack Compose 
1.0.0-alpha07
requires Kotlin 1.4.10. Looks like I'm forced to use some older version of JetBrains Compose.
j
Jetbrains also publishes the compatible Android artifacts, allowing you to easily share MPP code for exactly this reason. Is there a reason you aren't just using the android artifacts published by Jetbrains?
a
My library provides extensions for both Compose variants. So clients depending on their Compose variant choose an appropriate module from my library
So I have 
extensions-compose-jetpack
and 
extensions-compose-jetbrains
modules. Each uses the corresponding Compose variant. The former is pure Android library, the latter is multiplatform.
j
Ah, yeah, in the short term that might be a bit tricky. It should get better once the Compose APIs stabilize for our 1.0 release. And eventually I'd expect to merge the builds such that the mpp builds and google builds aren't separate.
👍 5
j
implementation(compose.material)
if there are specific APIs only for Android, then that implementation in 
androidMain
add them without having to add the Google one, like a normal MPP library? @jim
a
This would be awesome!
j
You can do that already, yes.
👍 1
I was assuming this was for release compatibility reasons, where 
extensions-compose-jetpack
needed to be compatible with a published alpha release of Compose on gmaven. If the concern is just being able to access android-specific APIs, then yes, just use 
androidMain
.
a
The problem is that I can't compile my whole project if I update Kotlin to 1.4.20 now. So I set 
kotlin_version
to 1.4.20, 
compose_jetpack_version
to 1.0.0-alpha07, and 
compose_jetbrains_version
to 0.2.0-build132. It does not compile 
extensions-compose-jetpack
module.
This also might be a problem for people with Multiplatform modules and Jetpack Compose in their projects. Because of Kotlin/Native we have to update Kotlin Version as soon as it is released. And Jetpack Compose is an anchor here.
j
I think maybe something is getting lost in translation here. If you are using the jetbrains desktop+android binaries, everything (including your 
extensions-compose-jetpack
) should compile with 1.4.20. The problem (as I understand it) is that you're trying to straddle both releases simultaneously for the purposes of providing your own releases that are compatible with both google+jetbrains latest releases, right?
a
Exactly this is the reason. I don't think I can publish 
extensions-compose-jetpack
with dependency on JetBrains Compose. Because Jetpack and JetBrains Compose are different publications in different repositories, and are not binary compatible.
Currently as a workaround, I think I can publish my library version 
x.y.z
with Kotlin 1.4.10 + version 
x.y.z-1420
with Kotlin 1.4.20 but without 
extensions-compose-jetpack
module.
j
yeah, probably you could also publish a variant of 
extensions-compose-jetpack
with 1.4.20 for use in MPP-android projects. That is to say, you publish two variants of all your artifacts (one for MPP users, and one for gmaven/android-only users). I understand this is very not ideal, but should hopefully only be short term.
a
Yep, thanks a lot!
j
@Arkadii Ivanov using snapshot is not possible?
a
I am aware about snapshots. Just want to stick with kinda stable releases. Also clients probably won't be able to compile their projects (or it may crash at runtime?), since they are using 1.4.10 and alpha07 version.
👍 1
a
you can also wait for alpha08. should be available next week
👍 1
Open in Slack
PreviousNext
Powered by