1.1.0 not publishing kotlin-api artifact for platform type common

[1gravity]

Unfortunately 1.1.0 doesn't publish a kotlin-api artifact for platform type common which leads to the following error if the consuming project doesn't have a hierarchical project structure:

Could not determine the dependencies of task ':module:compileKotlinMetadata'.
> Could not resolve all task dependencies for configuration ':module:metadataCompileClasspath'.
   > Could not resolve co.touchlab:kermit:{require 1.1.0; reject _}.
     Required by:
         project :project
      > The consumer was configured to find a usage of 'kotlin-api' of a library, preferably optimized for non-jvm, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'common'. However we cannot choose between the following variants of co.touchlab:kermit:1.1.0:
          - androidNativeArm32ApiElements-published
          - androidNativeArm64ApiElements-published
          - androidNativeX64ApiElements-published
          - androidNativeX86ApiElements-published
          - debugApiElements-published
          - debugRuntimeElements-published
          - iosArm32ApiElements-published
          - iosArm64ApiElements-published
          - iosSimulatorArm64ApiElements-published
          - iosX64ApiElements-published
          - jsIrApiElements-published
          - jsLegacyApiElements-published
          - jvmApiElements-published
          - jvmRuntimeElements-published
          - linuxArm32HfpApiElements-published
          - linuxMips32ApiElements-published
          - linuxX64ApiElements-published
          - macosArm64ApiElements-published
          - macosX64ApiElements-published
          - mingwX64ApiElements-published
          - mingwX86ApiElements-published
          - releaseApiElements-published
          - releaseRuntimeElements-published
          - tvosArm64ApiElements-published
          - tvosSimulatorArm64ApiElements-published
          - tvosX64ApiElements-published
          - watchosArm32ApiElements-published
          - watchosArm64ApiElements-published
          - watchosSimulatorArm64ApiElements-published
          - watchosX64ApiElements-published
          - watchosX86ApiElements-published
          ... more log outout

This is what's missing:

  "variants": [
    {
      "name": "metadataApiElements",
      "attributes": {
        "org.gradle.category": "library",
        "org.gradle.usage": "kotlin-api",
        "org.jetbrains.kotlin.platform.type": "common"

The current artifact only contains:

"variants": [
    {
      "name": "metadataApiElements",
      "attributes": {
        "org.gradle.category": "library",
        "org.gradle.usage": "kotlin-metadata",
        "org.jetbrains.kotlin.platform.type": "common"
      },

--> kotlin-metadata instead of kotlin-api, hence the error when using it as dependency with other than Android platforms.
All you need to do is to set this gradle flag:
kotlin.mpp.enableCompatibilityMetadataVariant=true

See also: https://kotlinlang.org/docs/multiplatform-hierarchy.html#for-library-authors

[kpgalligan]

Looks like 1.6.20 changed the default with this. I'm adding it back in, but I'm a little concerned as we've had issues with sourceset compatibility before. Also, the fact that this isn't on by default makes me think there will be some kind of compatibility issue that isn't clear right now, but we'll have to see.

It's not "other than Android platforms" also. I think it's just when you don't have hierarchical enabled. We use 1.1.0 in various non-Android contexts, but admittedly nothing that isn't hierarchical.

[kpgalligan]

https://github.com/touchlab/Kermit/releases/tag/1.1.1

[1gravity]

Thank you for updating so quickly.
When I try to use 1.1.1 now it can't find the classes any more (any of them). Checking the artifacts gradle downloads compared to 1.0.3 I can see

There are no more platform specific artifacts? What am I doing wrong?

[kpgalligan]

I honestly have no idea. 1.1.0 and 1.1.1 work in KaMP Kit and anything else I've tried it in. What version of Kotlin are you using, and how are you including the dependency?

[1gravity]

Kotlin 1.6.10 because 1.6.20 isn't compatible with Compose 1.1.1 (or vice versa).

val commonMain by getting {
            dependencies {
                implementation(Touchlab.kermit)

Touchlab.kermit resolves to co.touchlab:kermit:1.x.x

[kpgalligan]

Well, I don't know. We're not doing anything odd with the publishing, as far as I know. If you have a repro config that's failing, it would help. I'm running 1.6.10 for the same reason locally (Compose) and it seems to grab everything OK.

[1gravity]

I appreciate the help. I compiled KAmPKit with Kermit 1.1.1 and it worked perfectly. I also compared my setup with KAmPKit and modified it to get closer to what KAmPKit does but to no avail. My code is here:

git clone git@github.com:1gravity/Kotlin-Bloc.git
cd Kotlin-Bloc
git checkout feature/ios_support
./gradlew :blocCore:build 

this should compile but when I change version.kermit=1.0.3 to version.kermit=1.1.1 in the versions.properties file, it fails

[kpgalligan]

Looks like source set config for iOS. Looking at recent history, it looks like you changed ios() to the individual targets iosX64() etc, but then iosMain doesn't exist on its own.

This resolves dependencies, but I haven't tried to build it: https://github.com/kpgalligan/Kotlin-Bloc/tree/kpg/source_config

[1gravity]

Thank you. Will check it out later, on my way to the airport.

[1gravity]

Unfortunately not working. I'm working off the feature/ios_support not the main/master branch and the ios target setup seems to look good as far as I can see. Anyway, will look into it later. Thanks

[kpgalligan]

Ah, right. Different branch

On Wed, Apr 20, 2022 at 2:48 PM Emanuel Moecklin ***@***.***> wrote: Unfortunately not working. I'm working off the feature/ios_support not the main/master branch and the ios target setup seems to look good as far as I can see. Anyway, will look into it later. Thanks — Reply to this email directly, view it on GitHub <#244 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAQWIFHMGTZH4E26ZBRYODVGBGRFANCNFSM5TZOJNPA> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

-- Kevin Galligan https://twitter.com/kpgalligan

[kpgalligan]

I'm not sure if there's something special about your project layout or if my Android Studio install is having issues, but loading the project is like 20+ minutes. Maybe it just feels extra long or something. I didn't exactly time it. Time for a new laptop, maybe :) Waiting no dependency indexing...

[kpgalligan]

OK, it finished while I was tying that out.

[kpgalligan]

At this point I'd say I'm very confused. I've stripped back a bunch of things confounding the error messaging. I get to this point:

Execution failed for task ':blocCore:dataBindingMergeDependencyArtifactsDebug'.
> Could not resolve all files for configuration ':blocCore:debugCompileClasspath'.
   > Failed to transform kermit-debug.aar (co.touchlab:kermit-android-debug:1.1.1) to match attributes {artifactType=android-databinding, com.android.build.api.attributes.BuildTypeAttr=debug, org.gradle.category=library, org.gradle.status=release, org.gradle.usage=java-api, org.jetbrains.kotlin.platform.type=androidJvm}.
      > Could not find kermit-debug.aar (co.touchlab:kermit-android-debug:1.1.1).
        Searched in the following locations:
            https://plugins.gradle.org/m2/co/touchlab/kermit-android-debug/1.1.1/kermit-android-debug-1.1.1.aar

The Android plugin is attempting to do something with kermit-android-debug-1.1.1.aar, but it's only looking in:

https://plugins.gradle.org/m2/co/touchlab/kermit-android-debug/1.1.1/kermit-android-debug-1.1.1.aar

We don't deploy there. We deploy to mavenCentral. I don't know why it only looks there. However if I search for 1.0.3 at:

https://repo.gradle.org/ui/native/jcenter/co/touchlab/kermit-android-debug/1.0.3/kermit-android-debug-1.0.3.aar

It finds it. So, the obvious assumption is that repo.gradle.org is a mirror of repo1.maven.org.

Now, the listing for:

https://repo.gradle.org/ui/native/jcenter/co/touchlab/kermit-android-debug/1.1.1/

is there, but trying to grab the aar...

OK, while I was typing this all out, that file, the 1.1.1 aar, started downloading. But not from that link. It's really quite confusing.

I don't know what's happening with that. There's some kind of maven cache going on and some of the links work, some don't. I'm honestly pretty confused by the errors. I've never quite run into this.

[kpgalligan]

In any case, the project fails loading because it can't find that file, at least for me, but that's some crazy Android plugin stuff. Not sure why it only looks in that repo, and why that repo, which is apparently a mirror, isn't returning the file as expected. Need to put this on the shelf for now, but curious to see how this plays out. I was also getting errors for com.michael-bull.kotlin-result:kotlin-result-coroutines, so that would probably prevent project load as well.

[1gravity]

That was super helpful, the fix was easy, I simply switched the order of the two repos (gradlePluginPortal() and mavenCentral()). My assumption is that it finds some artifact on the plugin portal, maybe you guys deployed your plugin there initially? Anyway with mavenCentral() being the first repo, it seems to find the correct artifacts now and live is good again.
The com.michael-bull.kotlin-result:kotlin-result-coroutines issue was likely due to the fact that I used a locally deployed version (mavenLocal()) because I had to wait for the latest version 1.1.16 which also fixed the hierarchical project problem. Now 1.1.16 is out and I could remove the local artifact.
Thank you so much for your help, this almost drove me crazy...

[kpgalligan]

maybe you guys deployed your plugin there initially

We definitely didn't. That repo does have references from 1.1.1 as well, so it really seems like it's doing some kind of auto-mirror, but it also didn't get that version mirrored correctly. That's really weird, and honestly kind of frustrating. Anyway, glad you got it sorted out!

[kpgalligan]

Hmm. Now I have to think about this some. We do publish a grade plugin, but if it goes to the "official" plugin repo somehow, it must be doing it automatically. We never explicitly publish there. Seems plausible, although again frustrating that if so, it would attempt to pull in the entire package set. Something we should look into I guess.

[1gravity]

https://plugins.gradle.org/m2/co/ seems to be the "regular" plugin repository. When I open https://plugins.gradle.org/m2/co/touchlab it redirects to JFrog/Jcenter. The Gradle Plugin Portal is/was relying on JCenter before it was decommissioned (see e.g. https://blog.gradle.org/plugins-jcenter). My assumption is that JCenter is still mirroring Maven Central but only the JVM/Android artifacts and that's how it finds some of the required artifacts in the gradlePluginPortal() repo.
My mistake was to actually use gradlePluginPortal() in the allProjects configuration. plugins should only be used for the buildscript itself, so this is wrong:

allprojects {
    repositories {
        gradlePluginPortal()

[kpgalligan]

Wow. That's actually good info to get out there somewhere. Don't put gradlePluginPortal() in your regular repositories. I've seen similar situations, although not in KMP. I don't remember exactly where, but if a repo repo has a target version, but not the actual artifact, gradle won't continue looking at other repos. It'll fail. That does seem to be what's happening here.

[1gravity]

@kpgalligan btw I released the first version of my UI framework for Kotlin Multiplatform: https://1gravity.github.io/Kotlin-Bloc. I'm still working on the testing framework and the sample apps need some documentation but it's a first draft and it's ready to be battle tested. It's simpler and requires less boilerplate code than anything I've seen so far (Decompose, Orbit, Maverick, MVIKotlin, Ballast etc.). Maybe it's interesting for you and Touchlab.