Dependency mismatch
j3t opened this issue · comments
The current version of the library depends on different versions of org.jetbrains.kotlin:kotlin-stdlib-common (1.6.20 and 1.5.31) which leads to an error when the library is used in a project where the maven-enforcer-plugin is checking the dependencies (https://search.maven.org/artifact/com.squareup.okhttp3/okhttp/4.10.0/jar vs https://search.maven.org/artifact/com.squareup.okio/okio-jvm/3.0.0/jar).
I guess you just have to adjust the okhttp/build.gradle.kts like:
api(libs.squareup.okio) {
exclude(group = "org.jetbrains.kotlin", module = "kotlin-stdlib-common")
}
I would also suggest to check the dependencies during the build process to avoid dependency issue in general.
Source: https://github.com/jenkinsci/nomad-plugin/pull/143/checks?check_run_id=6853719409
This configuration is valid. What danger is the dependency enforcer plugin saving us from here?
What danger is the dependency enforcer plugin saving us from here?
I don't know how dependency conflicts are solved by gradle. In the worst case you will get an runtime error because a method was removed in one version or even worse, the order of the parameters has changed (see https://dzone.com/articles/solving-dependency-conflicts-in-maven).
Such things would constitute a binary breaking change which would mean every library in the world that used Kotlin would need to recompile from source.
I think we consider this expected, and sometimes completely unavoidable. We can't synchronize the world on a kotlin version. As @JakeWharton says we rely on strong promises/efforts with very visible notice when it has to break. https://kotlinlang.org/docs/kotlin-evolution.html
Going to close as not a bug.
We can't synchronize the world on a kotlin version.
Probably not, but for a particular OkHttp version you can. btw, it's not limited to kotlin, any dependency can cause version conflicts. This is well known issue with transative dependencies (see https://dzone.com/articles/solving-dependency-conflicts-in-maven).
@j3t I think the dependency enforcer plugin is being very defensive, and that might be appropriate by default. But the Kotlin stdlib is a library with very good backwards compatibility and in this case the warning is inappropriate.
I'm completely fine with that. I mean, OkHttp is a good option especially for older projects which are stuck to older java versions. I thought that is the focus but now it more clear, the project is more focused on Android and Gradle. The fact that you are publishing artifacts to maven central is just a coincidence.
This version delta is also safe for Maven users. The dependency enforcer plugin is too strict.
Version conflicts with transitive dependencies is a common problem. The enforcer plugin makes those conflicts just transparent. Sure, you can still have the standpoint that this is not my problem because it works for me, but then you just delegate the problem to the user and they have to solve it. For us this means we have to relax the enforcer rule or we have to pin org.jetbrains.kotlin:kotlin-stdlib-common to specific version.
Yeah agreed that many libraries are not great when it comes to backwards compatibility. Kotlin is thankfully very good here.
I recommend relaxing the rule in this case.