I am modernizing a Gradle 2.1 project to Gradle 4.10 in preparation for migrating to 5.x when it is available in the company.
As part of that, one of the problems the developers face is to manage dependencies in a consistent and visible way. Currently they have a map int hr
rootProject with dependencies for various artifacts, but it is being used inconsistently and many dependencies have explicit versions declared at the reference site.
What we want is to have the dependencies declared without versions and have all the versions declared in an easy to understand central location. I was thinking of using the Nebula dependency recommender, but then I read somewhere that Gradle now satisfies this use case with its BOM support.
So I wrote BOMs, in fact 3 of them, for different layers of the application (the APIs need to use older versions of certain libraries, etc). The BOMs cannot be published for administrative reasons, so I checked them in under
So far so good, but when I tried to add the BOMs as
file(...) dependency, they didn’t do anything (because they were added to the classpath, not interpreted as metadata).
My next attempt was to lay them out as a
file:...Maven repo and add them as artifacts. This is slightly better - I can see the BOMs present in every configuration, but no versions are resolved. I looked through the debug logs, but could not find details of why the BOMs were not used for the dependency resolution.
By BOM I mean a
*.pom file, with
pom packaging, no
dependency section and with
dependencyManagement section. The dependencies under
dependencyManagement have GAV coordinates and nothing else. Versions often reference properties.
What we really need is to make sure that any versionless dependencies are always listed in the BOM and the version is always what we see in the bom (even if transitive deps will fetch a higher version).
Nice-to-have 1: be able to see which explicit dependencies have versions not coming from the BOM.
Nice-to-have 2: fail the build if a transitive dep requires higher version than the BOM.
I realize that may be too much, so I would like to know which of these requirements can be satisfied with BOMs, for which do I need to use the constraint DSL, resolution strategies (or any other new mechanisms added in the 4.x releases).
Also any tips of why the local BOM didn’t work or where is the code that adds the constraints for BOM-ed versions would be welcome.