I develop a Spring Boot 2.0.x application which uses Gradle 5.2.1 to import multiple Maven BOMs, both custom and official Spring BOMs. Therefore, I use the platform
syntax provided by Gradle. However, I use the dependency-management
plugin in combination with the Spring Boot Gradle Plugin, too.
apply plugin: 'io.spring.dependency-management'
apply plugin: 'org.springframework.boot'
dependencies {
compile platform("org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}")
compile platform("com.myOrg:custom-bom:${latestVersion}")
}
According to the docs this combination of plugins triggers the inclusion of the Spring Boot BOM file. However, I do not know how this implicitly included BOM fits into the regular order of BOMs. Is it applied first and thus can be overridden by other BOMs or is it applied last and thus dominates all other BOM files?
In a Gradle world with only platform
usage for BOMs, there is no precedence rule. Gradle will consider all constraints brought in by the different BOMs and transitive dependencies and conflict resolve them in the usual fashion if they recommend different versions.
I am not a specialist of the Spring dependency-management
plugin, but my understanding is that it aims at replicating the Maven BOM contract: versions of the BOM overrule any transitive version and can in turn be overruled by local version declarations.
If that understanding is correct, then the dependency-management
plugin will apply its rules for all dependencies that are covered by the BOMs it imports. Anything not covered by the plugin will obey the Gradle rules.
In that sense, the mix might not be an ideal situation, as changes in BOM content over version in either direction could have pretty serious impact on resolved dependencies.