Should Kotlin libraries use Maven scope

provided

for their dependency on kotlin-stdlib?

I'm not that familiar with maven, but looking at https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope:

provided

This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.

That doesn't seem to be the right scope, the JDK doesn't provide the stdlib, right? It's just an ordinary dependency.

I was thinking the Kotlin application provides it, but forgot that it's not a given that the consumer is written in Kotlin.

let me know if you figure out a scope that does make sense

compile

?

ideally the kotlin dependency shouldn't be included in the library, it feels awkward

That doesn't mean it is included, does it? It's just a standard transitive dependency, the end user's build system can figure it out.

Correct. Gradle/Maven put information into the POM file, which is a sort of ‘I need these things to build, and can’t be built without them’ list. None of the jars/libraries defined in the build.gradle/pom.xml are included in the libraries jar.

The end result is that it has to be included. It's not good that my Java users have to pull in Kotlin dependencies.

The problem with a Kotlin library declaring a dependency on kotlin-stdlib (which is unavoidable) is that Gradle's conflict resolution defaults to highest version, i.e., my library might override the stdlib version declared by my library's users. I'd much rather have their version win, which is how Maven works.

yup, i was convinced by someone to port my library to kotlin when i wasn't aware of this

all my services and clis are written in kotlin, but my libraries aren't (unless they specifically target kotlin or aren't meant for broad consumption)

sounds like the way to go