Spring AI Simplify dependency management and avoid inconsistencies in apps

Expected Behavior Build is compiling and testing against dependencies that are actually used in apps for a given Spring Boot generation.

Current Behavior Build may or may not depending how accurate the overrides for certain versions are. Override for things like Jackson, Spring Framework, PostgreSQL are unnecessary.

Context The build uses the Spring Boot BOM which provides dependency management for a number of Spring and third party dependencies. This BOM is enforced in most Spring-based apps so deviating from that does not make much sense as whatever choice that's made here can't really be enforced without override in user's app.

Comment From: markpollack

Thanks for bringing this up. Aside from the autoconfig module, the rest of the compile time dependencies on spring boot are in testing code. So for example the Cassandra vector store implementation doesn't depend on boot classes.

But I guess we would want to pick up the version from Spring boot nevertheless except if we have a conflict to work around in autoconfig?

I see the following overlaps of managed boot deps and explicitly managed deps.

        <!-- also managed by boot bom -->
        <oracle.version>23.4.0.24.05</oracle.version>
        <postgresql.version>42.7.2</postgresql.version>
        <cassandra.java-driver.version>4.18.1</cassandra.java-driver.version>
        <elasticsearch-java.version>8.13.3</elasticsearch-java.version>
        <spring-retry.version>2.0.9</spring-retry.version>
        <jackson.version>2.16.1</jackson.version>
        <!-- not sure if jsonSchema is also managed by boot bom -->
        <jackson-module-jsonSchema.version>2.17.2</jackson-module-jsonSchema.version>
        <!-- check on kotlin version as managed by boot bom -->
        <kotlin.version>1.9.25</kotlin.version>

and for test deps

        <!-- testing dependencies also managed by boot bom-->
        <httpclient5.version>5.3.1</httpclient5.version>
        <testcontainers.version>1.20.1</testcontainers.version>

Comment From: snicoll

But I guess we would want to pick up the version from Spring boot nevertheless except if we have a conflict to work around in autoconfig?

I don't think that's very realistic. Whatever conflict forces you to use a different version means that conflict will surface back in user's projects. If there is a conflict, I'd rather raise that with the Spring Boot team to see if there's something that can be done at the source.

Comment From: markpollack

I need more clarification here. We have made a good deal of effort to remove all spring boot dependencies other than in autoconfig, so think of it like spring kafka. like spring cloud, we can run integration tests again different version of spring boot to ensure everything is working. I'd appreciate any guidance you can provide.

Comment From: snicoll

Me as well.

We have made a good deal of effort to remove all spring boot dependencies other than in autoconfig

I don't understand what that means. Where can I read about these efforts? Do you have a commit reference I can review?

Comment From: markpollack

There were a few commits, basically if you look in the pom.xml for any of the modules aside from autoconfig/starters - there are no dependencies on boot.

https://github.com/sobychacko/spring-ai/commit/79efa7f670154de7c2a31e5f15f362e123d588b8 is one of them.

Comment From: markpollack

ah, now I see your point. we will keep the

<dependencies>
   <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-dependencies</artifactId>

and get rid of the property based versions. sorry for the crossed wires.