RequireUpperBoundDeps error message is difficult to decipher

[archiecobbs]

Affected version

3.6.1

Bug description

In certain situations the error reported by RequireUpperBoundDeps is hard to decipher.

For example, this error:

[ERROR] Rule 0: org.apache.maven.enforcer.rules.dependency.RequireUpperBoundDeps failed with message:
[ERROR] Failed while enforcing RequireUpperBoundDeps. The error(s) are [
[ERROR] Require upper bound dependencies error for org.springframework.data:spring-data-commons:3.4.5. Paths to dependency are:
[ERROR] +-com.example:enforcer-bug:0
[ERROR]   +-com.vaadin:vaadin-core:24.9.1
[ERROR]     +-com.vaadin:vaadin-core-internal:24.9.1
[ERROR]       +-com.vaadin:vaadin-core-components:24.9.1 (managed) <-- com.vaadin:vaadin-core-components:24.9.1
[ERROR]         +-com.vaadin:vaadin-combo-box-flow:24.9.1 (managed) <-- com.vaadin:vaadin-combo-box-flow:24.9.1
[ERROR]           +-org.springframework.data:spring-data-commons:3.4.5 (managed) <-- org.springframework.data:spring-data-commons:3.5.4
[ERROR] and
[ERROR] +-com.example:enforcer-bug:0
[ERROR]   +-com.vaadin:vaadin-core:24.9.1
[ERROR]     +-com.vaadin:vaadin-core-internal:24.9.1
[ERROR]       +-com.vaadin:vaadin-core-components:24.9.1 (managed) <-- com.vaadin:vaadin-core-components:24.9.1
[ERROR]         +-com.vaadin:vaadin-grid-flow:24.9.1 (managed) <-- com.vaadin:vaadin-grid-flow:24.9.1
[ERROR]           +-org.springframework.data:spring-data-commons:3.4.5 (managed) <-- org.springframework.data:spring-data-commons:3.5.4
[ERROR] ]

(Note, you have to look carefully - the version mismatch is between 3.4.5 and 3.5.4).

If you inspect com.vaadin:vaadin-combo-box-flow:24.9.1 and com.vaadin:vaadin-grid-flow:24.9.1 you will see that they both declare this dependency:

<dependency>
    <groupId>org.springframework.data</groupId>
    <artifactId>spring-data-commons</artifactId>
    <version>3.5.4</version>
    <scope>compile</scope>
</dependency>

Yet the error message seems to be complaining that they are actually depending on 3.4.5 instead of 3.5.4 when you look at the +- child relationships.

The dependency on 3.4.5 is coming from the parent and you can see it in the help:effective-pom. But this is not at all obvious from the error message. In the error message, the 3.4.5 dependency is seemingly coming from "nowhere".

A contributor to this problem is that the website for RequireUpperBoundDeps does not explain how to interpret the error messages.

Would it be possible to explain this kind of conflict more clearly? Thanks.

Below is a POM that reproduces this situation when you run mvn validate.

<project
  xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>3.4.5</version>
    </parent>
    <groupId>com.example</groupId>
    <artifactId>enforcer-bug</artifactId>
    <name>Enforcer bug</name>
    <version>0</version>
    <packaging>war</packaging>

    <properties>
        <maven-enforcer-plugin.version>3.6.1</maven-enforcer-plugin.version>
        <vaadin.version>24.9.1</vaadin.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>com.vaadin</groupId>
            <artifactId>vaadin-core</artifactId>
        </dependency>
    </dependencies>

    <!-- Import vaadin-bom to define all the Vaadin dependency versions -->
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>com.vaadin</groupId>
                <artifactId>vaadin-bom</artifactId>
                <version>${vaadin.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-enforcer-plugin</artifactId>
                <version>${maven-enforcer-plugin.version}</version>
                <executions>
                    <execution>
                        <id>maven_enforcer</id>
                        <phase>validate</phase>
                        <goals>
                            <goal>enforce</goal>
                        </goals>
                        <configuration>
                            <rules>
                                <requireUpperBoundDeps>
                                    <excludes>
                                        <exclude>com.fasterxml.jackson.core:jackson-core</exclude>
                                        <exclude>com.fasterxml.jackson.core:jackson-databind</exclude>
                                        <exclude>com.fasterxml.jackson.datatype:jackson-datatype-jsr310</exclude>
                                        <exclude>com.google.guava:guava</exclude>
                                        <exclude>commons-codec:commons-codec</exclude>
                                        <exclude>io.netty:netty-all</exclude>
                                        <exclude>io.projectreactor.netty:reactor-netty</exclude>
                                        <exclude>org.apache.commons:commons-lang3</exclude>
                                        <exclude>org.apache.commons:commons-text</exclude>
                                        <exclude>org.jspecify:jspecify</exclude>
                                        <exclude>org.slf4j:slf4j-api</exclude>
                                    </excludes>
                                </requireUpperBoundDeps>
                            </rules>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

[dhruv9b]

Hi @archiecobbs,

I looked into this issue and agree that the current RequireUpperBoundDeps error message can be difficult to interpret, particularly when dependency management changes the resolved version.

I reproduced the behavior and prepared a fix that changes the output from:

1.0.0 (managed) <-- 2.0.0

to:

1.0.0 (managed; requested 2.0.0)

This makes it clearer that 1.0.0 is the version selected by dependency management, while 2.0.0 is the version requested by that dependency path.

I also added a regression test for the managed-version case and a short documentation clarification explaining the notation.

I've opened a PR with the changes: #1022

[archiecobbs]

Hi @dhruv9b, awesome, thanks a lot!