Provide dumb klibs for annotation and collection modules with dependencies on androidx artifacts #1819

eymar · 2025-01-31T17:08:05Z

To avoid breaking compilation compatibility with already published klibs depending on our klibs, we can't stop publishing an artifact with old coordinates: org.jetbrains.compose.annotation-internal and org.jetbrains.compose.collection-internal.

Here is why: https://youtrack.jetbrains.com/issue/KT-61096/KLIB-Resolve-Drop-KLIB-resolve-inside-the-Kotlin-compiler
TL;DR: All klibs have an explicit dependencies list. Kotlin expects that those klibs (with expected names) will be provided for compilation. If some klibs have org.jetbrains.compose.annotation-internal in that list, then the compilation will crash if there is no klib with such a name provided to compilation.

But the actual content in the klibs doesn't matter.
Therefore we keep publishing empty klibs. And add a dependency on androidx artifacts.

A bit of context:
Initially, we thought we can simply publish a .pom file with relocation info - basically a redirecting link. It works - gradle correctly resolves the dependencies and chooses the androidx artifact.
But Kotlin klibs resolver doesn't care about artifact relocations or substitutions (in gradle/maven perspective), Kotlin doesn't know about them.

The publication structure didn't change

The difference is that the .klib files are smaller now: 3-4 Kbytes.

The gradle metadata contains the dependency:

dependencies": [
        {
          "group": "androidx.annotation",
          "module": "annotation",
          "version": {
            "requires": "1.9.1"
          }
        },

And for example compose runtime depends on both old and new coordinates:

"dependencies": [
        {
          "group": "androidx.annotation",
          "module": "annotation",
          "version": {
            "requires": "1.9.1"
          }
        },
        {
          "group": "androidx.collection",
          "module": "collection",
          "version": {
            "requires": "1.5.0-beta02"
          }
        },
...
        {
          "group": "org.jetbrains.compose.annotation-internal",
          "module": "annotation",
          "version": {
            "requires": "25.1.31" // my local version
          }
        },
        {
          "group": "org.jetbrains.compose.collection-internal",
          "module": "collection",
          "version": {
            "requires": "25.1.31"
          }
        },

…ncies on androidx artifacts

MatkovIvan

It sounds like we cannot ever drop any of the dependencies from the publishing. It shouldn't be the case - we're planning to remove some libs in a few other places.

Needs to be discussed before moving forward

MatkovIvan · 2025-02-03T14:43:05Z

annotation/annotation/src/commonMain/kotlin/EmptyFile.kt

Can we keep commonMain in the same state as in AOSP?

Why would you like to keep commonMain the same? I believe we don't need to synchronize the source code of these modules anymore.

If we keep the source code, then the klib will include the symbols and the klib won't be "dumb" anymore. It will lead to symbols duplication, which is solved by keeping the klib's source code dumb/empty.

It sounds like we cannot ever drop any of the dependencies from the publishing.

It will be possible after https://youtrack.jetbrains.com/issue/KT-61096/KLIB-Resolve-Drop-KLIB-resolve-inside-the-Kotlin-compiler is solved.
Not immediately though, because we will want to support the previously published klibs.

Why would you like to keep commonMain the same

We aim to restore the state of all files in the fork that we don't maintain. It reduces merge/build issues.

We have 3 options:

delete all classes from commonMain, exclude the folder from merge in scripts/mergeAOSP.sh

somehow remove classes from publication on the build.gradle level (rename sourcesets?)

create additional collection-compatibility-stub, etc with the same group, exclude collection from settings.gradle

I vote for the latest - seems easy, and doesn't add issues.

Implemented the latest option.

MatkovIvan · 2025-02-03T14:44:08Z

collection/collection/build.gradle

-                implementation(libs.kotlinTest)
-                implementation(libs.kotlinTestAnnotationsCommon)
-                implementation(libs.kotlinCoroutinesCore)
+                api("androidx.collection:collection:1.5.0-beta02")


Please use a version from catalog

It is a pinned version, and we currently don't have pinned versions in version catalogs.

I don't mind to have them there, but we have to explicitly decide to do that as the general approach.

If you talk about libraryversions.toml - we can't use it, can elaborate more if needed.

Also, when we depend on not a Stable version, we should create a task to replace it by Stable with Target version: Compose 1.8

https://youtrack.jetbrains.com/issue/CMP-7495/Update-pinned-dependencies-before-navigation-stable-release

MatkovIvan · 2025-02-03T14:45:34Z

compose/runtime/runtime/build.gradle

                implementation(project(":annotation:annotation"))
                implementation(project(":collection:collection"))
-                implementation(project(":performance:performance-annotation"))
+                implementation("androidx.annotation:annotation:1.9.1")
+                implementation("androidx.collection:collection:1.5.0-beta02")


Use a version from catalog file

Can we use Google version for all modules?

Can we use Google version for all modules?

I think yes. We don't need to use a project dependency in all other modules.
Compose runtime is unavoidable dependency of any Compose project.

I mean I still don't fully understand why we should continue to publish it in case of removing all dependencies to it

I still don't fully understand why we should continue to publish it in case of removing all dependencies to it

There are many published 3rd party klibs which depend on compose-runtime 1.7.x and older.

Those 3rd party klibs contain a list of all dependencies (including transitive dependencies). The list contains the unique names of the dependencies-klibs, including org.jetbrains.compose.collection-internal that we were publishing.

When Kotlin consumes one klib, it expects that all the dependencies are supplied (paths to those dependencies-klibs).
If we stop publishing our dumb klib with unique name org.jetbrains.compose.collection-internal, then no klib path would be provided and Kotlin would report an error about missing klib.

Does this mean that we just need to publish only one no-op version and then remove it from publishing?

Those 3rd party klibs contain a list of all dependencies (including transitive dependencies). The list contains the unique names of the dependencies-klibs, including org.jetbrains.compose.collection-internal that we were publishing.

So, how are we going to drop experimental dependencies in the future? Like ui-backhandler that is supposed to be replaced by Google one once it will be there

Does this mean that we just need to publish only one no-op version and then remove it from publishing?

Not that simple unfortunately.
In order to be provided to Kotlin compiler, the dependency must be present in the dependency graph (configured by gradle).

Yes, we can stop publishing the dumb klib. But we will need to pin the dependency on the previously published dumb klib.

So, how are we going to drop experimental dependencies in the future? Like ui-backhandler that is supposed to be replaced by Google one once it will be there

We'll need the "dumb klib" approach too. The published dumb klib version can be used as a pinned dependency in one of our modules, so it will be present in the dependencies graph.

It will be possible after https://youtrack.jetbrains.com/issue/KT-61096/KLIB-Resolve-Drop-KLIB-resolve-inside-the-Kotlin-compiler is solved.

As we discussed privately, this won't solve the issue. We should publish it until we decide to drop backward compatibility.

A case explaining the issue:

App -> Compose 1.8 -> android.compose.annotation 1.5 App -> SomeLib -> Compose 1.7 -> org.jetbrains.compose.annotation-internal 1.7

Without a dumb lib:

App -> Compose 1.8 -> org.jetbrains.compose.annotation-internal 1.8

It will always lead to duplicated classes

Yes, we can stop publishing the dumb klib.

We also discussed it. If we stop publishing klib in Compose 1.9, for example, Compose 1.9 again won't be able to consume libs dependent on Compose 1.7

What Ivan and I mean is that we can stop publishing the dumb klib and add a module dependency on the dumb klib, while also adding a module dependency on the latest androidx.annotation. So the dependency graph would look like this:

org.jetbrains.compose.runtime:1.9 // future version | -> org.jetbrains.compose.annotation-internal:1.8.0 // dumb klib. The version we'll publish with CM 1.8.0. | -> androidx.annotation:1.9.1 | -> androidx.annotation:2.0 // 2.0 is just an example of future version

This way androidx.annotation:2.0 would be chosen.

Right?

igordmn · 2025-02-07T14:13:18Z

annotation/annotation/src/commonMain/kotlin/EmptyFile.kt

Why would you like to keep commonMain the same

We aim to restore the state of all files in the fork that we don't maintain. It reduces merge/build issues.

We have 3 options:

delete all classes from commonMain, exclude the folder from merge in scripts/mergeAOSP.sh

somehow remove classes from publication on the build.gradle level (rename sourcesets?)

create additional collection-compatibility-stub, etc with the same group, exclude collection from settings.gradle

I vote for the latest - seems easy, and doesn't add issues.

igordmn · 2025-02-07T14:17:33Z

collection/collection/build.gradle

-                implementation(libs.kotlinTest)
-                implementation(libs.kotlinTestAnnotationsCommon)
-                implementation(libs.kotlinCoroutinesCore)
+                api("androidx.collection:collection:1.5.0-beta02")


https://youtrack.jetbrains.com/issue/CMP-7495/Update-pinned-dependencies-before-navigation-stable-release

igordmn · 2025-02-07T14:26:01Z

compose/runtime/runtime/build.gradle

                implementation(project(":annotation:annotation"))
                implementation(project(":collection:collection"))
-                implementation(project(":performance:performance-annotation"))
+                implementation("androidx.annotation:annotation:1.9.1")
+                implementation("androidx.collection:collection:1.5.0-beta02")


It will be possible after https://youtrack.jetbrains.com/issue/KT-61096/KLIB-Resolve-Drop-KLIB-resolve-inside-the-Kotlin-compiler is solved.

As we discussed privately, this won't solve the issue. We should publish it until we decide to drop backward compatibility.

A case explaining the issue:

App -> Compose 1.8 -> android.compose.annotation 1.5 App -> SomeLib -> Compose 1.7 -> org.jetbrains.compose.annotation-internal 1.7

Without a dumb lib:

App -> Compose 1.8 -> org.jetbrains.compose.annotation-internal 1.8

It will always lead to duplicated classes

Yes, we can stop publishing the dumb klib.

We also discussed it. If we stop publishing klib in Compose 1.9, for example, Compose 1.9 again won't be able to consume libs dependent on Compose 1.7

igordmn · 2025-02-07T14:59:16Z

compose/runtime/runtime/build.gradle

@@ -116,9 +116,16 @@ if(AndroidXComposePlugin.isMultiplatformEnabled(project)) {
            commonMain.dependencies {
                implementation(libs.kotlinStdlibCommon)
                implementation(libs.kotlinCoroutinesCore)
+                implementation(project(":performance:performance-annotation"))
+
+                // Keep both project and module dependency for pseudo-relocated modules.


It looks like we don't have to add dependencies on androidx artifacts until we remove the project dependency?

Every project now depends on our dumb artifact

Every project depends on androidx artifact via transitive dependency

When we decide to remove the dumb artifact (breaking binary compatibility for old versions), we just replace the project dependency by androidx.

P.S. If something in my logic is wrong, and we still have to do it, we have to do it everywhere, not only in compose:runtime

Currently we don't need to add a module dependency on "androidx.collection/annotation:version".
It will be added transitively thanks to the dependecy on the stub project/module.
So I removed it for now.

But when we decide to stop publishing the stub, we'll need to add an explicit version dependency.

This reverts commit 039dabb.

… dependencies on androidx artifacts" This reverts commit 94706ce.

…tation:annotation

…ection:collection

eymar added 2 commits January 31, 2025 17:58

Provide dumb klibs for annotation and collection modules with depende…

94706ce

…ncies on androidx artifacts

remove Empty classes

039dabb

igordmn requested review from MatkovIvan and igordmn January 31, 2025 17:14

MatkovIvan reviewed Feb 3, 2025

View reviewed changes

igordmn reviewed Feb 7, 2025

View reviewed changes

eymar added 5 commits February 10, 2025 11:05

Revert "remove Empty classes"

0e6845c

This reverts commit 039dabb.

Revert "Provide dumb klibs for annotation and collection modules with…

e15a597

… dependencies on androidx artifacts" This reverts commit 94706ce.

add :annotation:annotation-compatibility-stub module to replace :anno…

f8845ac

…tation:annotation

add :collection:collection-compatibility-stub module to replace :coll…

784ec20

…ection:collection

docs improvement

00e0842

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Provide dumb klibs for annotation and collection modules with dependencies on androidx artifacts #1819

Provide dumb klibs for annotation and collection modules with dependencies on androidx artifacts #1819

eymar commented Jan 31, 2025 •

edited

Loading

MatkovIvan left a comment

MatkovIvan Feb 3, 2025

eymar Feb 3, 2025

eymar Feb 3, 2025 •

edited

Loading

igordmn Feb 7, 2025

eymar Feb 10, 2025

MatkovIvan Feb 3, 2025

igordmn Feb 3, 2025 •

edited

Loading

igordmn Feb 3, 2025 •

edited

Loading

igordmn Feb 7, 2025

MatkovIvan Feb 3, 2025

eymar Feb 3, 2025

MatkovIvan Feb 4, 2025

eymar Feb 4, 2025

MatkovIvan Feb 4, 2025

MatkovIvan Feb 4, 2025

eymar Feb 4, 2025 •

edited

Loading

eymar Feb 4, 2025 •

edited

Loading

igordmn Feb 7, 2025 •

edited

Loading

eymar Feb 10, 2025

igordmn Feb 7, 2025

igordmn Feb 7, 2025

igordmn Feb 7, 2025 •

edited

Loading

igordmn Feb 7, 2025

eymar Feb 10, 2025

Provide dumb klibs for annotation and collection modules with dependencies on androidx artifacts #1819

Are you sure you want to change the base?

Provide dumb klibs for annotation and collection modules with dependencies on androidx artifacts #1819

Conversation

eymar commented Jan 31, 2025 • edited Loading

MatkovIvan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eymar Feb 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

igordmn Feb 3, 2025 • edited Loading

Choose a reason for hiding this comment

igordmn Feb 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eymar Feb 4, 2025 • edited Loading

Choose a reason for hiding this comment

eymar Feb 4, 2025 • edited Loading

Choose a reason for hiding this comment

igordmn Feb 7, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

igordmn Feb 7, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eymar commented Jan 31, 2025 •

edited

Loading

eymar Feb 3, 2025 •

edited

Loading

igordmn Feb 3, 2025 •

edited

Loading

igordmn Feb 3, 2025 •

edited

Loading

eymar Feb 4, 2025 •

edited

Loading

eymar Feb 4, 2025 •

edited

Loading

igordmn Feb 7, 2025 •

edited

Loading

igordmn Feb 7, 2025 •

edited

Loading