Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
barchetta opened this issue Mar 15, 2024 · 14 comments
Open

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

barchetta opened this issue Mar 15, 2024 · 14 comments
Labels
bug Bug in existing code

Comments

@barchetta
Copy link

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?

@barchetta barchetta added the bug Bug in existing code label Mar 15, 2024
@JakeWharton
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link

Any plans to fix this for Maven users, please?

@JakeWharton
Copy link
Collaborator

It's already fixed in the 5.0 alphas.

@sashirestela
Copy link

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
Copy link
Collaborator

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
Copy link
Collaborator

yschimke commented Jun 4, 2024

Do you have a link for the right plugin?

@JakeWharton
Copy link
Collaborator

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

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

langchain4j pushed a commit to langchain4j/langchain4j that referenced this issue Aug 27, 2024
…roduced by `okhttp` dependency in 19 modules. (#1645)

## Issue

#1506

## Change

Resolved version conflict:
```
[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] +-dev.langchain4j:langchain4j-ollama:jar:0.34.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] +-dev.langchain4j:langchain4j-ollama:jar:0.34.0-SNAPSHOT
[ERROR]   +-com.squareup.okhttp3:okhttp:jar:4.12.0:compile
[ERROR]     +-org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.8.21:compile
[ERROR]
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <args> -rf :langchain4j-ollama
```

... caused by 'okhttp' dependency and enabled Maven enforcer plugin in
the following modules:

- LangChain4j :: Integration :: Anthropic
- LangChain4j :: Integration :: ChatGLM
- LangChain4j :: Integration :: Chroma
- LangChain4j :: Integration :: CloudFlare Workers AI
- LangChain4j :: Integration :: Cohere
- LangChain4j :: Integration :: DashScope
- LangChain4j :: Integration :: Hugging Face
- LangChain4j :: Integration :: Jina
- LangChain4j :: Integration :: Judge0
- LangChain4j :: Integration :: MistralAI
- LangChain4j :: Integration :: Nomic
- LangChain4j :: Integration :: OVHcloud AI
- LangChain4j :: Integration :: Ollama
- LangChain4j :: Integration :: Qianfan
- LangChain4j :: Integration :: Vearch
- LangChain4j :: Integration :: Vespa
- LangChain4j :: Integration :: Zhipu AI
- LangChain4j :: Web Search Engine :: SearchApi
- LangChain4j :: Web Search Engine :: Tavily

## Note

Please note that [issue ](square/okhttp#8288)
for this was already created in `httpok` repository but it will not be
fixed in 4.x. It's reportedly already tackled in version 5.x.

With that in mind I suggest we apply temporary changes proposed in this
PR. After upgrading to `httpok` 5.x we will be able to remove these.

## Tests

`mvn clean test` passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Bug in existing code
Projects
None yet
Development

No branches or pull requests

4 participants