gradle - Applying platform constraints to all configurations

Question

How do I inherit constraints from BOMs for all configurations in an ergonomic way ? The following is how I am currently doing it. I am on Gradle 6.6.1.

dependencies {
    compileOnly(platform('x:y:z'))
    implementation(platform('x:y:z'))
    annotationProcessor(platform('x:y:z'))
    testAnnotationProcessor(platform('x:y:z'))
    testImplementation(platform('x:y:z'))
    testCompileOnly(platform('x:y:z'))
}

question from:https://stackoverflow.com/questions/65842725/applying-platform-constraints-to-all-configurations

Answer 1

Well, you could do it by abusing the configurations.all method like this:

// Groovy DSL
configurations.all { config ->
    project.dependencies.add(config.name, project.dependencies.platform('x:y:z'))
}

But you don't need to add the platform to all those configurations in the first place. Because most of them are resolvable and extend both api and implementation, you typically only need to add it to one of those. The only exception is annotationProcessor, which is isolated (but is extended by testAnnotationProcessor). So you can still reduce it to:

// Groovy DSL
dependencies {
   implementation platform('x:y:z') // or api
   annotationProcessor platform('x:y:z')
}

This is in my opinion more readable and more precise.

A common use case is for Spring Boot. It could look like this:

// Groovy DSL
import org.springframework.boot.gradle.plugin.SpringBootPlugin

plugins {
    id 'java'
    id 'org.springframework.boot' version '2.4.2'
}

dependencies {
    // BOMS (Note that using the "BOM_COORDINATES" variable makes it match the version of the plugin)
    implementation platform(SpringBootPlugin.BOM_COORDINATES)
    annotationProcessor platform(SpringBootPlugin.BOM_COORDINATES)

    // Actual dependencies
    implementation 'org.springframework.boot:spring-boot-starter'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    annotationProcessor 'org.springframework.boot:spring-boot-configuration-processor'
}

Interestingly, there is a Gradle issue on this exact use case. Here they explained that typically you don't need this functionality, and where you do it is better to be explicit about it rather than just "hammer" a set of dependency versions onto everything.