I have some questions for the JB team with regards...

# multiplatform

[kpgalligan]

I have some questions for the JB team with regards to gradle and metadata. On the native side, as far as I know, to publish gradle dependencies we need to use the metadata feature. This is problematic because it is new and not yet stable, so different versions of gradle (and by extension metadata) are incompatible. The concrete manifestation of this is that most examples and as far as I know all JB libraries are published with 4.7. Android gradle 3.3 needs 4.10, which has a breaking version of metadata. It seems that the native side is continuing with the metadata approach (here: https://github.com/JetBrains/kotlin-native/commit/f68f7028b10ce6f8cd195faaee2c78fd8432ddf1), but that that isn't a universal plan (here: https://github.com/Kotlin/kotlinx.coroutines/issues/564#issuecomment-427885994). The ability to publish dependencies in a predictable way is critical for adoption, so I'm wondering about plans in the near term (continued in thread...)

[kpgalligan]

I've shifted to 4.10 mostly for the libraries I've been working on, due to the Android dependency, and under the assumption that the rest of the library "universe" would move that way as well, but I've been looking at commits in the libraries (the various kotlinx, ktor, etc), and and I don't see much discussion about it.

[kpgalligan]

So, I'm wondering about JB plans. Is 4.10+ in the works, or is 4.7 staying for the foreseeable future? Some other resolution? Understanding the roadmap will help with figuring out a plan.

[ilya.matveev]

Yes, Kotlin/Native will continue metadata approach because currently it's this most natural way to provide several variants of the same artifact.

Of course we plan to switch to a newer metadata versions. There is no final decision yet but most probably 1.3.20 will support Gradle 4.10/5.x metadata.

[kpgalligan]

Thanks! For now we're just directly referencing klibs, which isn't ideal but lets us work with 4.10

[kpgalligan]

if(System.getenv('SDK_NAME')?.startsWith("iphoneos")) {
implementation files('libs/atomicfu/ios_arm64/atomicfu-native.klib')
implementation files('libs/coroutines/ios_arm64/kotlinx-coroutines-core-native.klib')
}else{
implementation files('libs/atomicfu/ios_x64/atomicfu-native.klib')
implementation files('libs/coroutines/ios_x64/kotlinx-coroutines-core-native.klib')
}

[ilya.matveev]

You also can reference a maven dependency with a platform-specific klib:

targets {
    fromPreset(presets.iosX64, 'ios')
    fromPreset(presets.macosX64, 'macos')
    fromPreset(presets.iosArm64, 'iosSim')

    configure([ios, macos, iosSim]){
        compilations.main {
            def attributes = project.configurations.getByName(compileDependencyConfigurationName).attributes
            def targetAttribute = attributes.keySet().find {
                it.name == "org.jetbrains.kotlin.native.target"
            }
            def target = attributes.getAttribute(targetAttribute)
            dependencies {
                implementation "org.jetbrains.kotlinx:atomicfu-native_debug_$target:0.11.10-eap13"
                implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core-native_debug_$target:0.30.2-eap13"
            }
        }
    }
}

But there is a problem with transitive dependencies in this case. E.g. platform artifacts of coroutines have dependencies on a "root" maven artifact of atomicfu (org.jetbrains.kotlinx:atomicfu-native) in their pom-files. But we cannot resolve a platform variant for such a "root "dependency because metadata is disabled. So we have to declare all transitive dependencies manually as well as in your example.

[kpgalligan]

That's great. Much better than referencing the files. The method I was using has a similar transitive dependency issue anyway. Will give this a shot.