Hello,
We're working on upgrading to Kotlin 2.1.21 and we've seen that com.google.devtools.ksp:symbol-processing-aa-embeddable:2.1.21-2.0.2 is now a required dependency of kspKotlin. We see that this entails taking a dependency on a 60MB uberjar with duplicated classes that are present in the classpath through their original Maven coordinates. The dependency is not clear in the pom, it's pulled directly by the Gradle plugin at runtime. See the following table to see the conflicts we found
Package Conflicts
| Package |
Shared Classes |
Overlap % |
| org.jetbrains.kotlin:kotlin-annotation-processing-gradle |
639 |
5.7% |
| org.jetbrains.kotlin:kotlin-annotation-processing-embeddable |
213 |
1.9% |
| org.jetbrains.kotlin:kotlin-build-common |
68 |
0.6% |
| org.jetbrains.kotlin:kotlin-native-utils |
29 |
0.3% |
| org.jetbrains.kotlin:kotlin-build-statistics |
17 |
0.2% |
| org.jetbrains.kotlin:kotlin-util-klib |
15 |
0.1% |
| org.jetbrains.kotlin:kotlin-build-tools-api |
13 |
0.1% |
| org.jetbrains.kotlin:kotlin-daemon-client |
12 |
0.1% |
| org.jetbrains.kotlin:kotlin-daemon-embeddable |
12 |
0.1% |
| com.google.devtools.ksp:symbol-processing |
10 |
0.1% |
This dependency wasn't required in 2.0.21-1.0.28 but it seems required for 2.1.21-2.0.2. I have the following questions
- Is this really required?
- If it is required, can the classes be shaded to avoid classpath conflicts or removed completely?
- If it is required, can you have it in the pom as well?
This is prone to creating classpath conflicts in our build tools, which are messy to solve.
Hello,
We're working on upgrading to Kotlin 2.1.21 and we've seen that
com.google.devtools.ksp:symbol-processing-aa-embeddable:2.1.21-2.0.2is now a required dependency ofkspKotlin. We see that this entails taking a dependency on a 60MB uberjar with duplicated classes that are present in the classpath through their original Maven coordinates. The dependency is not clear in the pom, it's pulled directly by the Gradle plugin at runtime. See the following table to see the conflicts we foundPackage Conflicts
This dependency wasn't required in 2.0.21-1.0.28 but it seems required for 2.1.21-2.0.2. I have the following questions
This is prone to creating classpath conflicts in our build tools, which are messy to solve.