Hello, does anyone have a link or a slack thread t...

# multiplatform

[Justin Tullgren]

Hello, does anyone have a link or a slack thread that explains how to publish KMP libraries as pure native (AAR/XCFramework) to respective repos (maven central/spm) without shipping the klib?

I have two libs A & B. B exposes A via api(A) in commonMain dependencies. The gradle metadata resolution fails when depending on B in a third location C. C needs to use both A and B types but the A types are not available on the compile path. Any ideas?

[Marcin Kiżewski]

AAR:
• You can use gradle's ``maven-publish`` built-in plugin with configured maven central account
• Or use vanniktech's plugin gradle-maven-publish-plugin https://github.com/vanniktech/gradle-maven-publish-plugin
◦ It even has article on how to upload to maven central inside its documentation: https://vanniktech.github.io/gradle-maven-publish-plugin/central/
◦ And it's also used inside Kotlin's documentation: https://kotlinlang.org/docs/multiplatform/multiplatform-publish-libraries-to-maven.html
XCFramework:
• There is an article inside Kotlin Multiplatform documentation on how to distribute KMP library as XCFramework on SPM: https://kotlinlang.org/docs/multiplatform/multiplatform-spm-export.html

[Marcin Kiżewski]

As if it goes for why metadata resolution fails, it may be caused by many things. api() dependency declarations works different in multiplatform projects than in JVM project. It may surfaced because of some custom source sets hierarchies or KGP mismatches.

You can try to migrate to implementation of A in both B and C or if possible provide how are A and B configured.

[Justin Tullgren]

we need to publish release only aars to maven central but we publish debug aars internally. we need to differentiate by artifact id and not by metadata like gradle does. the maven pom works and if I set up

mavenLocal {
  mavenPom()
}

it works and resolves via maven but i am concerned that enforcing

mavenCentral {
  mavenPom()
}

will break a lot of integrations people have.

We know we are messing with the pom to make sure we have a -debug postfix and the pom transitive depends are correctly marked but when it comes to gradle resolution it fails.

The required “Release” only to maven central is a company policy. But we have an internal artifactory repo with both debug and release for testing and debugging and we simply move the release one to maven central.

[Marcin Kiżewski]

Messing with pom may be the issue, as there's also .module file that could be still used for dependency graph resolution. You can try to disable its autogeneration to force use pom file as a single source of truth

[Marcin Kiżewski]

Also it's worth checking out gradle's --refresh-dependency flag when messing with external dependencies to force reload cached ones: https://docs.gradle.org/current/userguide/dependency_caching.html#sec:refreshing-dependencies

[Chrimaeon]

You might want to publish different „variants“.
https://docs.gradle.org/current/userguide/variant_aware_resolution.html#sec:understanding-variant-selection
You can ask questions about this in the Gradle community slack. https://gradle.org/slack-invite

[Justin Tullgren]

thank you both. i’ll check them out