Publish a Gradle version catalog for Spring Boot's own modules

[jnizet]

Gradle now supports version catalogs, which have the advantage of generating type-safe accessors to reference the dependencies, allowing, for example

testImplementation(libs.mockk)

with support for auto-completion.

Such version catalogs can be defined in the build itself, but can also be published and then consumed by other projects. Micronaut for example does that, allowing to do in the settings files

    versionCatalogs {
        create("mn") {
            from("io.micronaut:micronaut-bom:3.3.0")
        }
    }

and then in the build files

dependencies {
    implementation(mn.picocli)
}

Overriding versions from the imported catalog is supported too.

Publishing such a version catalog along with the Spring Boot BOM would be a nice feature, which would allow migrating away from the spring dependencies plugin, now that gradle seems to support its features (with version catalogs and with the platform plugin), and benefit from the additional advantage of type-safe accessors for dependencies.

[wilkinsona]

Thanks for the suggestion, @jnizet.

The main stumbling block that I encountered when looking at version catalogs in the past was that I don't think it's possible for a catalog to import a third-party bom or another catalog. Unless things have changed since I last looked, and looking at the API I can't see that they have, we'd have to stop using the boms of third-party libraries and instead manually declare each module in that library in our own catalog. That's possible of course, but it's quite a bit of extra work. We'd probably then need to write some validation tasks to ensure that our catalog covers everything that's in each third-party bom that we were using previously.

That said, the dependency management plugin is also a non-zero amount of work. If it's going to live on, it really needs to be modernised (probably building on Gradle's constraints support) as the current codebase only uses APIs that were available in Gradle 2.x. It's testament to Gradle's backwards compatibility that it continues to work but we can't rely on that forever. I'll flag this one for discussion at a team meeting so that we can decide how best to spend our time in this area.

[jnizet]

Great, thanks @wilkinsona .

[Fleshgrinder]

I asked for BOM support but sadly the response was that this isn't going to happen. gradle/gradle#19142

[wilkinsona]

Unfortunately, a version catalog isn't a useful replacement for the dependency management plugin for the same reasons that Gradle also has its own bom support with platform and enforcedPlatform dependencies. The dependency management plugin has two key capabilities:

1. Manage the versions of transitive dependencies
2. Easy one-line version overrides

Gradle's platform support offers 1 and version catalogs offer 2. Unfortunately, easily overriding the versions of transitive dependencies is not possible even if you use a platform and a version catalog in combination. With some regret, this means that we'll have to continue to maintain and recommend the use of the dependency management plugin. Our plan is to modernise it in time for Boot's 3.0 release towards the end of this year.

We'll leave this issue open as a version catalog for Boot would still provide some benefits. For example, auto-completion for Boot's starters would be a nice developer experience improvement. It's a fairly small improvement, though, so we don't expect to tackle it any time soon.

[Fleshgrinder]

2. is provided in many places in Gradle and can be as simple as adding dependencies { implementation("group:module:version-override") }. The version catalogs play no role here, as they are just used to declare versions that can then be used in build scripts in a type-safe manner. Resolution is entirely decoupled from this. We are using just the Spring BOM without the plugin since a long time without any issues, and we are upgrading the dependencies we need to upgrade by simply declaring a dependency on our own (which is the correct way to do so in any event, because if my code depends on it than I should declare a direct dependency on it).

Maybe I'm missing something?

[wilkinsona]

For single-module libraries declaring a dependency is indeed quite concise. Things get considerably more verbose when the library has multiple modules.

As an example, if you have a dependency on spring-boot-starter-web and you want to use a specific version of Tomcat, with the dependency management plugin you can configure tomcat.version and you're done:

ext["tomcat.version"] = "9.0.56"

Without the dependency management plugin you could declare individual dependencies but you'd have to know which dependencies to declare and what to exclude to retain the starter's behaviour. It might look something like this:

implementation("org.apache.tomcat.embed:tomcat-embed-core:9.0.56") {
    exclude group: "org.apache.tomcat", module: "tomcat-annotations-api"
}
implementation("org.apache.tomcat.embed:tomcat-embed-el:9.0.56")
implementation("org.apache.tomcat.embed:tomcat-embed-websocket:9.0.56") {
    exclude group: "org.apache.tomcat", module: "tomcat-annotations-api"
}

Another option would be to define some constraints for the three Tomcat modules or a resolution strategy to set their version but neither would be as concise or as declarative as setting the version property.

which is the correct way to do so in any event, because if my code depends on it than I should declare a direct dependency on it

I don't think this is as simple as one way being correct and, therefore, others being incorrect. I think it's subjective and comes down to a team's personal preferences. We know that many Spring Boot users enjoy the concision and ease-of-use of the various starter modules and deliberately avoid direct dependencies on every module their code depends upon in favour of a single dependency that gives them everything they need.

[Fleshgrinder]

Agree, the real problem with your example is that the vendor does not provide a platform (BOM), otherwise it would boil down to a single dependency declaration again. It is very true that this situation is as it is in the majority of the JVM ecosystem. Some vendors even make it worse by publishing artifacts under the same name as others with different versioning schemes (looking at you Confluent). A good question for your example to the vendor would also be why it forces the annotations upon us, if clearly most users have no use for them (safe to say most if Spring excludes it).

I don't think this is as simple as one way being correct and, therefore, others being incorrect. I think it's subjective and comes down to a team's personal preferences. We know that many Spring Boot users enjoy the concision and ease-of-use of the various starter modules and deliberately avoid direct dependencies on every module their code depends upon in favour of a single dependency that gives them everything they need.

We also heavily work with trusting transitives and using transitives to give us what we need. I really meant this in the context of the answer where I want to control a transitive dependency because my code requires a special version of it. In that case using the dependency extension of the plugin or declaring a dependency directly boils down to being exactly the same thing. We just have two different APIs in use.