Dependency convergence issue with kotlin-stdlib-jdk8 (via okio)

[barchetta]

okhttp3:4.12.0 depends on kotlin-stdlib-jdk8:1.8.21

okio:3.6.0 (which okhttp3:4.12.0 depends on) depends on kotlin-stdlib-jdk8:1.9.10

This means any project that uses okhttp3:4.12.0 and wishes to enforce dependency convergence fails the check with:

[ERROR] Rule 0: org.apache.maven.enforcer.rules.dependency.DependencyConvergence failed with message:
[ERROR] Failed while enforcing releasability.
[ERROR]
[ERROR] Dependency convergence error for org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.9.10 paths to dependency are:
[ERROR] +-me.example:example-mp:jar:1.0-SNAPSHOT
[ERROR]   +-com.squareup.okhttp3:okhttp:jar:4.12.0:compile
[ERROR]     +-com.squareup.okio:okio:jar:3.6.0:compile
[ERROR]       +-com.squareup.okio:okio-jvm:jar:3.6.0:compile
[ERROR]         +-org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.9.10:compile
[ERROR] and
[ERROR] +-me.example:example-mp:jar:1.0-SNAPSHOT
[ERROR]   +-com.squareup.okhttp3:okhttp:jar:4.12.0:compile
[ERROR]     +-org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.8.21:compile

Is it possible for you to align on a common version of kotlin with okio?

[JakeWharton]

And so the problem here is that Maven otherwise nonsensically chooses the nearest one, right? Rather than choosing the newest one, as one would expect.

We merge the latest versions in both repositories as soon as they're available now. I wouldn't expect this to happen again.

Does Maven 4 fix this?

[barchetta]

No, in this case Maven is choosing exactly the versions specified by the deployed artifacts:

https://repo1.maven.org/maven2/com/squareup/okhttp3/okhttp/4.12.0/okhttp-4.12.0.pom https://repo1.maven.org/maven2/com/squareup/okio/okio-jvm/3.6.0/okio-jvm-3.6.0.pom

[JakeWharton]

According to Maven's docs it should not: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

Maven picks the "nearest definition". That is, it uses the version of the closest dependency to your project in the tree of dependencies.

I would expect it to pick 1.8.21. Isn't that the purpose of running the tool which is failing?

Looks like Gradle has a built-in solution to preventing this whose use will have a side-effect of preventing Maven's bonkers default strategy from doing something no one wants: https://docs.gradle.org/current/userguide/resolution_strategy_tuning.html#fail-version-conflict.

[barchetta]

Oh, by "choose" you meant how does Maven perform dependency version conflict resolution. That misses the point. The point is to avoid dependency version conflicts in the first place.

I would expect it to pick 1.8.21.

So you end up running with a version of a dependency that okio did not intend. And if you pick the latest you end up with a version of a dependency that okhttp did not intend. Both are bad.

Isn't that the purpose of running the tool which is failing?

No. The purpose of the enforcer tooling is to catch dependency version conflicts during development so that you do not release artifacts with dependency version conflicts. Similar to the Gradle solution you referenced.

[yschimke]

So you end up running with a version of a dependency that okio did not intend. And if you pick the latest you end up with a version of a dependency that okhttp did not intend. Both are bad.

Kotlin has good semantic versioning, and OkHttp relies on this, so you can update other dependencies as you see fit.

OkHttp 4.12.0 expects you to use any version of kotlin greater than or equal to 1.8.21. We don't rush out a release each time okio releases with a newer Kotlin. This isn't a thing we worry about at all.

[barchetta]

All I'm requesting is that when you pick up a new version of okio you also update okhttp's kotlin dependencies to match what is used by that version of okio.

[JakeWharton]

Outside of the Maven semantics there is no actual conflict here, to be clear. The Kotlin stdlib promises this to be a compatible configuration (along with nearly every other library in existence, apart from major version bumps). Because of Gradle's default resolution strategy of choosing the newest in the transitive tree, our tests for that version of OkHttp were even running with 1.9.10 so we know it's a valid configuration.

We inherit our the stdlib version declaration from the Kotlin Gradle plugin automatically. It's possible a build problem was holding back our plugin upgrade at the time. Or maybe we simply didn't merge the Renovate PRs as eagerly back then. It might even predate our use of Renovate to bump dependencies. The 4.x branch is a few years old at this point.

When I find time I'll try the Gradle config. For Maven users (or anything Aether-based?) it's an actual correctness bug.

Gradle used to be Ivy-based but they switched to their own resolver years ago. I suspect Ivy in general behaves like Gradle, though. So anything using those won't actually see problems.

[yschimke]

It's possible a build problem was holding back our plugin upgrade at the time. Or maybe we simply didn't merge the Renovate PRs as eagerly back then. It might even predate our use of Renovate to bump dependencies. The 4.x branch is a few years old at this point.

Renovate is running on main, not on 4.x. So it's manual bumps for 4.11, 4.12 etc.

[sashirestela]

Any plans to fix this for Maven users, please?

[JakeWharton]

It's already fixed in the 5.0 alphas.

[sashirestela]

It is great you fix it in a pre-release version, but I'd really appreciate it if you could fix it for version 4.x also.

[JakeWharton]

I'm not really involved in that, but since this occurrence is benign in practice I'm not sure they're going to do a whole release just for that.

By the way, as a result of this issue there are now a few Gradle plugins in development which will prevent your dependency tree from creating this problem for Maven consumers. We should add one moving forward!

[yschimke]

Do you have a link for the right plugin?

[JakeWharton]

https://github.com/GradleUp/maven-sympathy

https://github.com/usefulness/maven-sympathy