Should Kotlin libraries use Maven scope `provided`...

# announcements

[pniederw]

Should Kotlin libraries use Maven scope provided for their dependency on kotlin-stdlib?

[karelpeeters]

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.

[pniederw]

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

[pniederw]

Hence you are right, provided doesn't make sense here.

[tipsy]

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

[karelpeeters]

compile?

[tipsy]

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

[karelpeeters]

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.

[Mike]

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.

[Mike]

So compile (or if you’re using a newer version of Gradle, api) would be the correct level.

[tipsy]

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

[pniederw]

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.

[pniederw]

@tipsy That's one of the reasons why it's safer to write libraries intended for broad consumption in Java. Another is that as much as I like Kotlin, I don't want to force Java users of my libraries to deal with (e.g., read, debug) Kotlin code.

[tipsy]

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

[tipsy]

i'm considering porting it back to java, but kotlin is a lot nicer..

[pniederw]

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)

[tipsy]

sounds like the way to go