ArafatKhan2198 commented on code in PR #9915:
URL: https://github.com/apache/ozone/pull/9915#discussion_r3263839920
##########
pom.xml:
##########
@@ -515,6 +569,26 @@
</exclusion>
</exclusions>
</dependency>
+ <dependency>
+ <groupId>dev.langchain4j</groupId>
+ <artifactId>langchain4j-anthropic</artifactId>
+ <version>0.36.2</version>
+ </dependency>
+ <dependency>
+ <groupId>dev.langchain4j</groupId>
+ <artifactId>langchain4j-core</artifactId>
+ <version>0.36.2</version>
+ </dependency>
+ <dependency>
+ <groupId>dev.langchain4j</groupId>
+ <artifactId>langchain4j-google-ai-gemini</artifactId>
+ <version>0.36.2</version>
+ </dependency>
+ <dependency>
+ <groupId>dev.langchain4j</groupId>
+ <artifactId>langchain4j-open-ai</artifactId>
+ <version>0.36.2</version>
+ </dependency>
Review Comment:
Thanks for the suggestion. In principle, using the `langchain4j-bom` is a
good idea and I agree it would make version updates cleaner. However, Ozone
manages all dependency versions centrally in the root `pom.xml` under
`<dependencyManagement>`, and every other third-party library in the project
follows this same pattern of individual version entries. Introducing a BOM
import for just this one library would be inconsistent with how the rest of the
project is structured.
Also, worth noting — the `<version>` tags you are seeing are only in the
root `pom.xml`'s `<dependencyManagement>` block. If you check `recon/pom.xml`,
the four LangChain4j dependency entries there have no `<version>` tags at all —
they inherit the version from the root. So there is already a single source of
truth for the version. Updating it in the future is still just one change in
the root `pom.xml`. Happy to add the BOM if there is a strong preference, but
it would require a broader discussion about whether Ozone should standardize
BOM imports for external libraries.
--
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]
