Spring-boot: Cannot override jackson.version using Gradle Dependency Management Plugin

[franzbecker]

Issue Description

In a Gradle project using the "Dependency Management Plugin" we can override a property as part of importing a BOM as documented here.

Now when we want to react quickly to an security audit problem, e.g. jackson-databind this mechanism is quite useful since we can do something like:

dependencyManagement {
     imports {
           mavenBom('org.springframework.boot:spring-boot-dependencies:2.1.7.RELEASE') {
            bomProperties([
                 'jackson.version': '2.9.9.20190807'
            ])
        }
     }
}

Now I would expect this to work since there is a jackson-bom with this particular version.

    <dependency>
        <groupId>com.fasterxml.jackson</groupId>
        <artifactId>jackson-bom</artifactId>
        <version>${jackson.version}</version>
        <scope>import</scope>
        <type>pom</type>
    </dependency>

See spring-boot-dependencies/pom.xml#L642

However, this fails with:

Could not find com.fasterxml.jackson.core:jackson-core:2.9.9.20190807

This is due to the fact that the Spring jackson.version seems to "shadow" the jackson.version property that the jackson-bom uses internally (see jackson-bom/pom.xml#L29) and Jackson recently adopted a different release scheme (https://github.com/FasterXML/jackson-databind/issues/2395#issuecomment-516527360).

With Maven this was probably not a problem since this kind of overriding properties was not allowed / documented (https://github.com/spring-projects/spring-boot/issues/12790#issuecomment-383205839) and could only be done by setting it externally with mvn ... -Djackson.version=x.y.z.

Standalone example

Can be found here: https://github.com/franzbecker/spring-bom-problem/blob/master/build.gradle

Related issues

https://github.com/spring-projects/spring-boot/issues/17698 previous discussion on this issue
https://github.com/spring-projects/spring-boot/issues/12790 similar discussion but the author had another issue

Possible solutions

Rename jackson.version to jackson-bom.version (proposed here https://github.com/spring-projects/spring-boot/issues/12790#issuecomment-381210632 as well).

I would argue that this naming would represent the semantics better as this property defines which version of the Jackson BOM is imported, not the Jackson version itself.

Another solution I could think of would be to allow a more fine-grained control of the overrides in the "Dependency Management Plugin".

[snicoll]

Thanks for the detailed report. I disagree that renaming jackson to jackson-bom is a solution as it's just working around the underlying problem as I understand it.

For those of you who are using 2.1.7 and are willing to use this version, here's a simplified build that does the job:

plugins {
    id 'org.springframework.boot' version '2.1.7.RELEASE'
    id 'java'
}

apply plugin: 'io.spring.dependency-management'

group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '1.8'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

dependencyManagement {
  imports {
    mavenBom 'com.fasterxml.jackson:jackson-bom:2.9.9.20190807'
  }
}

[wilkinsona]

Rename jackson.version to jackson-bom.version

I would argue that this naming would represent the semantics better as this property defines which version of the Jackson BOM is imported, not the Jackson version itself.

I find this argument compelling, particularly given the divergence of Jackson's version and its bom's version. It would also make things more consistent with Spring Data where we use spring-data-releasetrain rather than just spring-data for the property that controls the version of spring-data-releasetrain that is imported.

Another solution I could think of would be to allow a more fine-grained control of the overrides in the "Dependency Management Plugin".

Yes, I think any other change would have to be made in the dependency management plugin. For example, overrides could only be applied to properties in directly imported boms and not to those imported by an imported bom. That would, however, be a breaking change so it would probably need to be opt-in.