and i built a simple reproducer to demo the issue ...

# github-workflows-kt

[Nikky]

and i built a simple reproducer to demo the issue https://github.com/NikkyAI/KT-67618

[Vampire]

That repo does not really reproduce what you describe as the problem.

When you build that library, you use Gradle which uses the Gradle Module Metadata, which properly resolves the JVM variant so compiles just fine.

Then you use that library from script which does not use GMM, so does not use the JVM variant, so the classes are not found at runtime.

The BOM was used or it would fail at compile time. But it only uses io.ktor:ktor-client-cio, which does not have the class. Your library effectively has a provided dependency on io.ktor:ktor-client-cio-jvm when used from a non-Gradle consumer even though it does not declare it.

[Nikky]

this is weird either way and i wish we could use BOMs somehow.. alas..

i don't quite get how it reaches the end result that we are observing from what its doing.. but .. yeah .. the issue in youtrack was my best guess as to what might be happening

[Vampire]

As I said, for non-Gradle consumers the lib you publish effectively has 3 "provided" dependencies.
So if you add

@file:DependsOn("io.ktor:ktor-client-cio-jvm:2.3.10")
@file:DependsOn("io.ktor:ktor-client-content-negotiation-jvm:2.3.10")
@file:DependsOn("io.ktor:ktor-serialization-kotlinx-json-jvm:2.3.10")

to the main.kts script, it runs properly.

A Gradle consumer could automatically resolve them.
This is the same as with any feature variant that is published with Gradle.
It has dependencies that for non-Gradle consumers have to be added manually.

[Vampire]

This is not a problem of versions from BOM, but simply that non-Gradle consumers cannot resolve Gradle variants from Gradle Module Metadata but have to manually add the necessary dependencies or classifiers.

[Vampire]

An additional quirk is, that @file:DependsOn does not support dependencies without a version.

[Vampire]

For a non-multi-platform library, it is probably better to directly depend on the -jvm versions, as then also non-Gradle consumers can directly resolve the transitive dependencies.

[Nikky]

cc @Piotr Krzemiński

I agree with this.. at least for the workflows usecase, annoying that we have to work around scripting bugs

[Vampire]

Again, what you describe is not a scripting bug. It would be the same in a Maven project. Or on an Ivy project.

[Vampire]

Only Gradle consumers are capable enough to properly resolve Gradle feature variants.

[Nikky]

I suppose so, call it a limitation then shrug

[Nikky]

does feel like a design oversight in the KMM grade variants design.. or the BOMs of ktor are designed to be only consumed by gradle?

[Vampire]

Again, the BOM is working fine. And without Gradle Module Metadata you cannot model such feature variants properly, especially not in a convenient way as POM are simply not capable enough to express them.

So such feature variants are super comfortable and automatic for Gradle consumers and if someone else wants to consume them, he has to do some additional steps like depending on optional dependencies or using classifiers or like in this case using different coordinates