spring-boot-dependencies contains unwanted dependency management

[wilkinsona]

It's being inherited from log4j-bom. In 3.2.x (Log4j 2.21), it's contributing management for the following dependencies:

• biz.aQute.bnd:biz.aQute.bnd.annotation:6.4.1
• com.github.spotbugs:spotbugs-annotations:4.7.3
• org.osgi:osgi.annotation:8.1.0
• org.osgi:org.osgi.annotation.bundle:2.0.0
• org.apache.maven.plugin-tools:maven-plugin-annotations:3.9.0

In 3.3.x (Log4j 2.23), it's the following:

• biz.aQute.bnd:biz.aQute.bnd.annotation:7.0.0
• com.github.spotbugs:spotbugs-annotations:4.8.3
• org.jspecify:jspecify:0.3.0
• org.osgi:osgi.annotation:8.1.0
• org.osgi:org.osgi.annotation.bundle:2.0.0
• org.osgi:org.osgi.annotation.versioning:1.1.2
• org.apache.maven.plugin-tools:maven-plugin-annotations:3.10.2

In 3.4.x (Log4j 2.24), it's the following:

• biz.aQute.bnd:biz.aQute.bnd.annotation:7.0.0
• com.github.spotbugs:spotbugs-annotations:4.8.6
• org.jspecify:jspecify:1.0.0
• org.osgi:osgi.annotation:8.1.0
• org.osgi:org.osgi.annotation.bundle:2.0.0
• org.osgi:org.osgi.annotation.versioning:1.1.2
• org.apache.maven.plugin-tools:maven-plugin-annotations:3.13.1

I've opened apache/logging-log4j2#3066 to see if the bom can be improved to remove this unwanted dependency management. In the meantime, we may want to move away from using it.

[wilkinsona]

It's not just Log4j2's bom that is problematic. A prototype for #42523 has found the following problems in 3.2.x:

Brave
    - Imported bom io.zipkin.brave:brave-bom:5.16.0 contains dependencies that should not be managed:
        - io.zipkin.reporter2:zipkin-reporter-bom:2.16.3
        - io.zipkin.zipkin2:zipkin:2.23.2
Glassfish JAXB
    - Imported bom org.glassfish.jaxb:jaxb-bom:4.0.5 contains dependencies that should not be managed:
        - com.sun.istack:istack-commons-runtime:4.1.2
        - com.sun.xml.bind:jaxb-core:4.0.5
        - com.sun.xml.bind:jaxb-core:4.0.5:sources
        - com.sun.xml.bind:jaxb-impl:4.0.5
        - com.sun.xml.bind:jaxb-impl:4.0.5:sources
        - com.sun.xml.bind:jaxb-jxc:4.0.5
        - com.sun.xml.bind:jaxb-jxc:4.0.5:sources
        - com.sun.xml.bind:jaxb-osgi:4.0.5
        - com.sun.xml.bind:jaxb-xjc:4.0.5
        - com.sun.xml.bind:jaxb-xjc:4.0.5:sources
        - com.sun.xml.fastinfoset:FastInfoset:2.1.1
        - com.sun.xml.fastinfoset:FastInfoset:2.1.1:sources
        - jakarta.activation:jakarta.activation-api:2.1.3
        - jakarta.xml.bind:jakarta.xml.bind-api:4.0.2
        - jakarta.xml.bind:jakarta.xml.bind-api:4.0.2:sources
        - org.eclipse.angus:angus-activation:2.0.2
        - org.jvnet.staxex:stax-ex:2.1.0
        - org.jvnet.staxex:stax-ex:2.1.0:sources
Log4j2
    - Imported bom org.apache.logging.log4j:log4j-bom:2.21.1 contains dependencies that should not be managed:
        - biz.aQute.bnd:biz.aQute.bnd.annotation:6.4.1
        - com.github.spotbugs:spotbugs-annotations:4.7.3
        - org.apache.maven.plugin-tools:maven-plugin-annotations:3.9.0
        - org.osgi:org.osgi.annotation.bundle:2.0.0
        - org.osgi:osgi.annotation:8.1.0
Reactor Bom
    - Imported bom io.projectreactor:reactor-bom:2023.0.10 contains dependencies that should not be managed:
        - org.reactivestreams:reactive-streams:1.0.4

[wilkinsona]

To fix this, we'd have to stop using the boms from various projects. Currently, the worst offenders are Log4j and JAX-B. Unfortunately, moving away from using a bom has the downside that it makes it harder for users to upgrade to a new version of a library when that new version introduces a new module. They can no longer simply override the version property, instead they also have to declare dependency management for the new module.

3.5.x is the last minor in the 3.x line and will be an "LTS" release which increases the likelihood that users will want to upgrade to a new minor of a managed dependency during its lifetime. As such, I think it would be a mistake to move away from using the Log4j and JAX-B boms in 3.5.x. We can look at this in 4.0.x instead which will have a short support period as it will be followed by 4.1.x, 4.2.x, etc.