Open andersonkyle opened 6 years ago
The problem is that calling dependencyManagement.managedVersions
causes the imported boms to be resolved. This marks the dependency management as resolved. The subsequent import of the Spring Cloud bom doesn't change this so it's effectively ignored. The fix is to reset the resolved
flag each time a bom import is added.
There's a broader problem here, though. Using dependencyManagement.managedVersions
has the unwanted side-effect of causing dependency resolution (for the imported boms) before task execution occurs. It would be good to be able to avoid that but I'm not sure how to do so. The best idea I can come up with is to use a placeholder for the version that's then spotted by a resolution strategy and replaced with the property version.
The same broader problem also applies to dependencyManagement.importedProperties
which is discussed in #56. Using a placeholder may also work in that case.
To add another related use case, I would like to specify a version, but only if the version I am specifying is newer than the one that would otherwise be used. We would like to use the newer version because it includes a security fix, but whenever Spring Boot starts including a version that is newer than the one specified we would just want to use that. I attempted to use the dependencyManagement
API like others here but ran in to similar problems.
Gradle 6.5 has added support for declaring dependencies using a Provider
. The provider's evaluated lazily which avoids the problem of prematurely resolving the imported boms. The problematic dependency in the original example can be fixed by writing it like this:
implementation provider { 'io.dropwizard.metrics:metrics-jvm:' + dependencyManagement.managedVersions['io.dropwizard.metrics:metrics-core'] }
I'll turn this into a documentation issue for 1.0.x.
Here is the relevant snippet from my build.gradle file that reproduces this issue:
The problem occurs when I call the
dependencyManagement
API from within adependency {}
declaration.If this API call is removed, the
mavenBom
is imported as expected.Here is an example repo. To test whether the BOM is imported or not, use this command:
Spring Boot alone only contains about 5 Spring Cloud dependencies, so that's all you should see in the list. When you remove the API call mentioned above, you'll see dozens of Spring Cloud dependencies coming from the Spring Cloud BOM.
NOTE: Ordering seems to be a factor as if you move the
dependencyManagement {}
section above thedependencies {}
section, it works as expected, even when calling the dependencyManagement API within a dependency declaration.