Hello, I have 3 kmp library modules in same kmp project as follow: - `library-base` - `library-dat...

# multiplatform

[Dimitar G.]

Hello, I have 3 kmp library modules in same kmp project as follow:
• library-base
• library-data which "tries to" embed library-base via api(projects.libraryBase)
• librart-multi which adds library-data via api(projects.libraryData)
My problem is library-multi does not add library-data .
And library-data does not have library-base .

Calling
./gradlew :library-multi:publishAndroidReleasePublicationToMavenLocal
creates the needed AAR files, but I don't have these dependencies embed.

Here is a simple repo which provides the problem - https://github.com/dimitar71/multi-kmp.
Added a brief explanation of the issue.

You can run refapp, since it is an Android app module.

The issue which I am struggling is, that api(projects.libraryData) is not adding the source code when creating the AAR builds.

Can someone provide details what I am doing wrong?
Reading the docs around, using ChatGPT, Copilot, everything points that I am doing things right.
However, no luck.

[CLOVIS]

./gradlew library multipublishAndroidReleasePublicationToMavenLocal

This only publishes library-multi . If you want to use the other libraries, you have to publish them too!

[CLOVIS]

It's exactly the same in regular Android without KMP modules, by the way

If you instead run

./gradlew publishAndroidReleasePublicationToMavenLocal

then everything should work

[Dimitar G.]

Same problem, same error.

I am using api() (not implementation()).
So technically, library-data source code should be part of library-multi AAR.
But it is not, exactly the same error even when calling
./gradlew publishAndroidReleasePublicationToMavenLocal

[CLOVIS]

So technically, library-data source code should be part of library-multi AAR.

No, that's not what api() does. api() is the same as implementation() except it makes symbols available at compile-time. It doesn't touch the contents of the archive in any way.

[CLOVIS]

But it is not, exactly the same error even when calling

./gradlew publishAndroidReleasePublicationToMavenLocal

Are you sure? I've run your first command and the libraries were not in ~/.m2 , then after executing that one they were in ~/.m2 .

[CLOVIS]

Do you have a Gradle command to run the app? I don't have Android studio here

[Dimitar G.]

Will record a short video, 2 min

[Dimitar G.]

Here is the video, same problem

[Dimitar G.]

Screen Recording 2024-12-24 at 11.32.37 AM.mov

Screen Recording 2024-12-24 at 11.32.37 AM.mov

[CLOVIS]

uh your files are named weirdly

[Javier]

if you run ./gradlew publishToMavenLocal, is the issue fixed?

[CLOVIS]

what your build publishes is library-data-android , but what your build wants is library-data … Did you rename the artifacts somewhere?

[Dimitar G.]

This is how multiplatform works. It does this suffix at the end -android
The MAJOR problem I am having 🙂

[Javier]

It is a kmp library, that is the reason it has -android suffix

[CLOVIS]

No, that's not how normal KMP works. In a normal KMP module, there should be a common artifact too

[Javier]

As it is not running the whole publication, the files that contain the “wiring” to understand that calling it without -android should use -android are not being published

[Javier]

Try

./gradlew publishToMavenLocal

[CLOVIS]

Do:
• ./gradlew publishToMavenLocal
• ./gradlew :refapp:checkDebugAarMetadata
it should work

[Dimitar G.]

OMG!
Thank you!

Yes, ``publishToMavenLocal`` solved the problem

[CLOVIS]

Your problem is you're running:
:library-multi:publishAndroidReleasePublicationToMavenLocal

but that:
• only publishes :library-multi
• only publishes the AndroidReleasePublication
So you're not publishing :library-base nor :library-multi , and you're not publishing :library-multi 's common , only its android

[Dimitar G.]

So... does it mean I don't need to use api() ?

Or should api() still be needed?

[Javier]

That depends on what you want

[Javier]

if you want to get the dependencies transitively or explicitly

[CLOVIS]

api() and implementation() are different

If you're writing a module X, and you depend on a module Y

If X has a type from Y in any of its public declarations, you should use api() ("it's part of my API!")

If X only uses Y inside code but it never appears in public signatures, you should use implementation() ("it's part of my implementation!")

[Javier]

if you use api for a dependency in the module A, you don’t need to explicit declare that dependency in the module B and you will be able to see the symbols

[Dimitar G.]

I want them explicitly, since the whole idea is a "library" which consists of 5 small supplemental library modules.

However, couldn't go with BOM, since some of these lib modules are using core lib module.
A bit messy, but seems the only approach of what we are trying to achieve

[CLOVIS]

@Javier that's incorrect, both api() and implementation() are transitive. compileOnly and runtimeOnly are not transitive.

[Javier]

it being a library or not is not a reason to use only implementation or only api, it depends on what your consumers expect to do

[Javier]

if all APIs are necessary, having to add 5 libraries versus 1 would be annoying

[Dimitar G.]

I've always thought api() embeds code.
TIL is every day.

This library is a bit of everything - for some cases all 5, for others just core , hard to explain.

Is there a gradle ability to include (not just use, but include) a dependency into our own dependency?

[CLOVIS]

There are plugins for that (the key name is "shading") but in general it's a very bad idea, because it duplicates the contents of those libraries

[Javier]

@CLOVIS just semantics, the concept about what I mean there with transitively is clear, it is even shown in the docs

[Javier]

> Dependencies appearing in the api configurations will be transitively exposed to consumers of the library, and as such will appear on the compile classpath of consumers. Dependencies found in the implementation configuration will, on the other hand, not be exposed to consumers, and therefore not leak into the consumers' compile classpath. This comes with several benefits:

[Javier]

if your consumers will add all those libraries by default, always, create a core module which uses api on the rest of modules so your consumers can add ir easily

[CLOVIS]

@Javier that's much more nuanced than what you said (and a bit ambiguous).

api() :
• transitively available to consumers (runtimeClasspath)
• transitively exposed to consumers (compileClasspath)
implementation() :
• transitively available to consumers (runtimeClasspath)
• not exposed to consumers (compileClasspath)
sadly this is always explained in ambiguous ways so many people are confused 😕

[Javier]

@CLOVIS you are ignoring the context and the messages I shared, which are the key, as I talk about being able to use the symbols.

[CLOVIS]

…I'm responding to your very first message, there was no context there…

Anyway, the OP's problem is solved, there's no need to further debate this

[Javier]

I wrote two messages because I am from mobile, both are part of the context. You were too fast than I was able to be from mobile 😛

Agree about the problem is solved 👍

[Dimitar G.]

I want to thank both of you!
This was quick and on point!

Happy Holidays to both!
And cheers!

[CLOVIS]

Happy holidays! K