-
Notifications
You must be signed in to change notification settings - Fork 9.2k
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
Comments
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? |
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 |
According to Maven's docs it should not: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
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. |
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.
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.
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. |
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. |
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. |
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. |
Renovate is running on main, not on 4.x. So it's manual bumps for 4.11, 4.12 etc. |
Any plans to fix this for Maven users, please? |
It's already fixed in the 5.0 alphas. |
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. |
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! |
Do you have a link for the right plugin? |
…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
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:
Is it possible for you to align on a common version of kotlin with okio?
The text was updated successfully, but these errors were encountered: