Background
The org.springframework.boot plugin automatically imports the spring-boot-dependencies BOM if the io.spring.dependency-management is applied.
While this behaviour is convenient, it overrides explicit configuration done using the dependencyManagement extension, so it does not work as described here:
4.2.1. Importing Multiple Boms If you import more than one bom, the order in which the boms are imported can be important. The boms are processed in the order in which they are imported. If multiple boms provide dependency management for the same dependency, the dependency management from the last bom will be used.
I have described the issue in greater detail here, where I accidentally submitted an issue to the wrong project.
Proposal
In order to disable the behaviour, I have introduced the property org.springframework.boot.import-bom which can be set to false to disabling the import. It defaults to true to preserve the current behaviour.
Other ideas
I considered using SpringBootExtension instead of a property, but if the io.spring.dependency-management plugin is applied first, then there's no opportunity to configure the extension, since the dependency management configuration happens as soon as the org.springframework.boot plugin is applied. This could be worked around with afterEvaulate, but that would be a breaking change since the delaying of the import to afterEvaulate would mean that spring-boot-dependencies is always imported last (and order is important).
Comment From: pivotal-cla
@ryanflegel Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.
Comment From: pivotal-cla
@ryanflegel Thank you for signing the Contributor License Agreement!
Comment From: philwebb
Rather than having to opt-out, I wonder if the dependency plugin could offer a fallback option for us to configure? Something that's only used if the coordinates aren't already declared directly.
@ryanflegel Will you only need to disable our conventions so that you can include them again in your configuration for ordering?
Comment From: wilkinsona
Will you only need to disable our conventions so that you can include them again in your configuration for ordering?
Yes, that's the case @philwebb. There's some more info in https://github.com/spring-gradle-plugins/dependency-management-plugin/issues/398.
Comment From: ryanflegel
Yes, they will be included included manually by importing my own platform BOM. The platform BOM includes spring-boot-dependencies among other things.
The issue I'm having with the Boot plugin is that it's re-importing the spring-boot-dependencies BOM and overriding the versions there. In order to avoid this, I'd need to ensure that both the Boot plugin and Dependency Management plugin are applied before I import my platform BOM. It sounds simple, but it's actually very convoluted in a multi-project build where I'm declaring my imports in the root project using subprojects{}.
I did think about modifying the behaviour of DependencyManagementPluginAction to only import spring-boot-dependencies if it hadn't been imported yet, but I couldn't see a way to make that work since spring-boot-dependencies is not included in dependencyManagement.getManagedVersions() as a transitive BOM.
Comment From: philwebb
We discussed today as a team and decided to reopen https://github.com/spring-gradle-plugins/dependency-management-plugin/issues/398 so that we can provide a fallback/convention option in the dependency-management plugin. Once that's implemented we'll switch to use it in Spring Boot (see #43210). We decided that would probably be better than needing extra configuration.
Thanks anyway for the PR @ryanflegel