It fails with:
```
Configuration `:jvmRuntimeClasspath` contains AndroidX dependencies, but the `android.useAndroidX` property is not enabled, which may cause runtime issues.
:jvmRuntimeClasspath -> org.jetbrains.compose.desktop:desktop-jvm-linux-x64:0.0.0-dev1418 -> org.jetbrains.compose.desktop:desktop:0.0.0-dev1418 -> org.jetbrains.compose.desktop:desktop-jvm:0.0.0-dev1418 -> org.jetbrains.compose.material:material:0.0.0-dev1418 -> org.jetbrains.compose.material:material-desktop:0.0.0-dev1418 -> org.jetbrains.compose.annotation-internal:annotation:0.0.0-dev1418 -> androidx.annotation:annotation:1.7.1
:jvmRuntimeClasspath -> org.jetbrains.compose.desktop:desktop-jvm-linux-x64:0.0.0-dev1418 -> org.jetbrains.compose.desktop:desktop:0.0.0-dev1418 -> org.jetbrains.compose.desktop:desktop-jvm:0.0.0-dev1418 -> org.jetbrains.compose.material:material:0.0.0-dev1418 -> org.jetbrains.compose.material:material-desktop:0.0.0-dev1418 -> org.jetbrains.compose.annotation-internal:annotation:0.0.0-dev1418 -> androidx.annotation:annotation:1.7.1 -> androidx.annotation:annotation-jvm:1.7.1
:jvmRuntimeClasspath -> org.jetbrains.compose.desktop:desktop-jvm-linux-x64:0.0.0-dev1418 -> org.jetbrains.compose.desktop:desktop:0.0.0-dev1418 -> org.jetbrains.compose.desktop:desktop-jvm:0.0.0-dev1418 -> org.jetbrains.compose.foundation:foundation:0.0.0-dev1418 -> org.jetbrains.compose.foundation:foundation-desktop:0.0.0-dev1418 -> org.jetbrains.compose.collection-internal:collection:0.0.0-dev1418 -> androidx.collection:collection:1.4.0
:jvmRuntimeClasspath -> org.jetbrains.compose.desktop:desktop-jvm-linux-x64:0.0.0-dev1418 -> org.jetbrains.compose.desktop:desktop:0.0.0-dev1418 -> org.jetbrains.compose.desktop:desktop-jvm:0.0.0-dev1418 -> org.jetbrains.compose.foundation:foundation:0.0.0-dev1418 -> org.jetbrains.compose.foundation:foundation-desktop:0.0.0-dev1418 -> org.jetbrains.compose.collection-internal:collection:0.0.0-dev1418 -> androidx.collection:collection:1.4.0 -> androidx.collection:collection-jvm:1.4.0
```
(https://teamcity.jetbrains.com/buildConfiguration/JetBrainsPublicProjects_Compose_Publish_2_All_2/4484004?hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildTestsSection=true&expandBuildChangesSection=true&expandBuildDeploymentsSection=false&expandBuildProblemsSection=true)
after we added annotation/collection to desktop target dependencies.
It seems that Android plugin checks all JVM classpathes, including pure
JVM (desktop) ones. And fails, if the project doesn't have this
property.
Adding this property, as the Android fails without it as well.
The recent compose core libs are built using 1.9.21, and apparently, older k/native versions don't support them.
e: kotlin.NotImplementedError: Generation of stubs for class org.jetbrains.kotlin.ir.symbols.impl.IrTypeParameterPublicSymbolImpl is not supported yet
Reason:
Since Xcode 15, there is a new default setting:
`ENABLE_USER_SCRIPT_SANDBOXING = YES`
SyncComposeResourcesForIosTask fails to work with it right now.
Currently when `org.gradle.configuration-cache=true` we have an error:
> Configuration cache state could not be cached: field `resourceFiles`
of task `:shared:syncComposeResourcesForIos` of type
`org.jetbrains.compose.experimental.uikit.tasks.SyncComposeResourcesForIosTask`:
error writing value of type
'org.gradle.api.internal.provider.TransformBackedProvider'
Old description (can be ignored):
_This PR attempts to fix it in SyncComposeResourcesForIosTask by
wrapping inputs into providers. It seems that gradle configuration cache
doesn't like some provider types produced by `.map`, `.zip`, `.orElse`,
etc._
**Latest description:**
With configuration cache enabled, gradle runs all `orElse` providers
during configuration (I don't know why yet).
We used to throw an exception in `orElse` which led to the crash. This
PR refactors SyncComposeResourcesForIosTask so it doesn't throw an
exception immediately in orElse, but postpones it to later step.
Konstantin
Igor Demin
Oleksandr Karpovich
Shishkin Pavel
dima.avdeev
Alexander Maryanovsky
Alexander Zhirkevich