ArafatKhan2198 commented on code in PR #9915:
URL: https://github.com/apache/ozone/pull/9915#discussion_r3254921803
##########
hadoop-ozone/recon/pom.xml:
##########
@@ -62,6 +62,22 @@
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
</dependency>
+ <dependency>
+ <groupId>dev.langchain4j</groupId>
+ <artifactId>langchain4j-anthropic</artifactId>
Review Comment:
Thanks for pointing out the OkHttp dependency tree. I dug into this, and
because `okhttp` (pulled by LangChain4j) and `okhttp-jvm` (pulled by
OpenTelemetry) have different artifact IDs, Maven doesn't actually treat them
as a version conflict. This split happened because OkHttp 5.x moved to Kotlin
Multiplatform and shifted its core classes into the new `-jvm` artifact.
Because they are technically different artifacts, adding an `<exclusion>`
for `okhttp-jvm` inside the `langchain4j-anthropic` block won't have any
effect, since LangChain4j doesn't pull in `okhttp-jvm` to begin with (it only
pulls `okhttp` 4.x).
At runtime, both JARs will be present on the classpath. Fortunately, this
won't cause a problem because OkHttp 5.x is highly backward-compatible with
4.x. The JVM will simply load the `OkHttpClient` class from whichever JAR it
scans first, and both OpenTelemetry and LangChain4j will function normally.
If we ever want to strictly enforce a single OkHttp version across the
entire project to avoid classpath pollution, the safest way would be to manage
both `okhttp` and `okhttp-jvm` centrally in the root `hadoop-ozone/pom.xml`'s
`<dependencyManagement>` section. For the scope of this PR, though, it is safe
to leave as-is since it won't cause any runtime crashes.
##########
hadoop-ozone/recon/pom.xml:
##########
@@ -62,6 +62,22 @@
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
</dependency>
+ <dependency>
+ <groupId>dev.langchain4j</groupId>
+ <artifactId>langchain4j-anthropic</artifactId>
Review Comment:
Thanks for pointing out the OkHttp dependency tree. I dug into this, and
because `okhttp` (pulled by LangChain4j) and `okhttp-jvm` (pulled by
OpenTelemetry) have different artifact IDs, Maven doesn't actually treat them
as a version conflict. This split happened because OkHttp 5.x moved to Kotlin
Multiplatform and shifted its core classes into the new `-jvm` artifact.
Because they are technically different artifacts, adding an `<exclusion>`
for `okhttp-jvm` inside the `langchain4j-anthropic` block won't have any
effect, since LangChain4j doesn't pull in `okhttp-jvm` to begin with (it only
pulls `okhttp` 4.x).
At runtime, both JARs will be present on the classpath. Fortunately, this
won't cause a problem because OkHttp 5.x is highly backward-compatible with
4.x. The JVM will simply load the `OkHttpClient` class from whichever JAR it
scans first, and both OpenTelemetry and LangChain4j will function normally.
If we ever want to strictly enforce a single OkHttp version across the
entire project to avoid classpath pollution, the safest way would be to manage
both `okhttp` and `okhttp-jvm` centrally in the root `hadoop-ozone/pom.xml`'s
`<dependencyManagement>` section. For the scope of this PR, though, it is safe
to leave as-is since it won't cause any runtime crashes.
cc: @devmadhuu
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
