You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem will be solved if the runtime dependency on kotlinx-datetime-jvm will be added to the POM file. I think, similar problem arises in Maven projects as well.
The text was updated successfully, but these errors were encountered:
In Maven JVM projects you should depend explicitly on kotlinx-datetime-jvm variant, like you do with any other Kotlin/MPP library.
I don't know the details behind @file:DependsOn dependency resolution mechanism, but probably it could be taught to support Gradle metadata in some limited form to resolve the correct dependency variant.
It turns out there's some problem with the way we do it in coroutines: Kotlin/kotlinx.coroutines#3842. We'll need to look into it before we decide whether the datetime library should do the same.
Seems like the main artifact should be the JVM jar with the Gradle module metadata. Then the common artifact is a separate artifact ID, like how the stdlib works.
We in Kotlin Jupyter kernel use Maven resolver for libraries resolution. Maven POM for
kotlinx.datetime
lacks any information ofkotlinx-datetime-jvm
dependency: https://repo1.maven.org/maven2/org/jetbrains/kotlinx/kotlinx-datetime/0.3.1/kotlinx-datetime-0.3.1.pom.So, when we import library like this:
we end up with an almost empty JAR without
.class
files, it only contains metadata files.This fixes the issue:
The problem will be solved if the runtime dependency on
kotlinx-datetime-jvm
will be added to the POM file. I think, similar problem arises in Maven projects as well.The text was updated successfully, but these errors were encountered: