Enhancement: limit report to updates actionable in the context of pom.xml

[rmie]

I found nothing similar in closed issues, if you consider this a duplicate to a previous issue, feel free to close it.

Motivation:
I'm trying to limit the reports down to a point that all listed dependencies, plugins, parent and properties version are specified in the analyzed pom.xml. Basically all inherited (upstream) issues should be ignored. I want to make it as simple and fast as possible to fix such issues without the need to reason about if a reported issue is inherited from upstream.

Example: two projects, from different reactors

• parent/pom.xml uses spring-boot-starter-parent:3.3.1, but 3.3.3 is latest version
• service/pom.xml uses parent/pom.xml at latest version

report for

• parent/pom.xml
  • MUST list outdated parent
  • MUST NOT list e.g. outdated plugins, dependencies that are inherited from spring-boot-starter-parent
• service/pom.xml
  • MUST NOT list e.g. outdated parent, plugins etc. inherited from parent/pom.xml

Possible Solutions:

• preferred, additional flag e.g. ignoreInherited to control this behavior
• alternative, mark "inherited" issues in reports (and possibly xml) as such

[andrzejj0]

Have you tried setting processDependencyManagementTransitive to false?

[rmie]

Have you tried setting processDependencyManagementTransitive to false?

yes

[andrzejj0]

I can't reproduce the issue when using -DprocessDependencyManagementTransitive=false.

Please provide a minimal pom.xml (or set of maven projects) reproducing the issue.

For example, for the following pom.xml

<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/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.3.1</version>
  </parent>

  <groupId>localhost</groupId>
  <artifactId>parent</artifactId>
  <version>1.0.0-SNAPSHOT</version>

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>localhost</groupId>
        <artifactId>dummy-api</artifactId>
        <version>[1.0,2.3]</version>
        <scope>test</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>localhost</groupId>
      <artifactId>dummy-api</artifactId>
      <scope>compile</scope>
    </dependency>
  </dependencies>

</project>

mvn org.codehaus.mojo:versions-maven-plugin:2.18.0:dependency-updates-report -DprocessDependencyManagementTransitive=false

the report lists dummy-api as the only dependency having available dependency updates

[rmie]

The testcase is made up of two poms, parent/pom.xml and child/pom.xml, intentionally not placed in a single reactor build.

running mvn -f child/pom.xml' versions:display-dependency-updates gives

[INFO] The following dependencies in Dependencies have newer versions:
[INFO]   com.oracle.database.jdbc:ojdbc11 ............ 21.9.0.0 -> 23.6.0.24.10
...
[INFO] The following dependencies in pluginManagement of plugins have newer versions:
[INFO]   org.springframework.boot:spring-boot-maven-plugin ..... 3.3.4 -> 3.3.5

The version of neither of both is directly specified in child/pom.xml, but inherited from parent/pom.xml, and both are ignored by e. g. versions:use-latest-version. This makes it hard to reason about what e. g. versions:use-latest-version will change.

[andrzejj0]

I'm missing the actual pom.xml files to be able to reproduce your case.

[rmie]

I'm missing the actual pom.xml files to be able to reproduce your case.

sorry forgot to upload testcase.zip

[andrzejj0]

Thanks for the update. Not exactly sure how to tackle this. The plugin has a history and its goals do differ in behaviour ever so slightly. For example, use-latest-versions doesn't process any dependencies within build plugins or pluginManagement, display-dependency-updates does do it (which can be disabled e.g. by processPluginDependencies or processPluginDependenciesInPluginManagement), hence it displays the updates there (spring-boot-maven-plugin) whereas use-latest-versions doesn't.

Regarding the version of ojdbc11 -- it's assigned by Maven based on parent of the parent. This should probably not be reported by display-dependency-updates especially considering the fact that you did disable transitive dependencies.

use-latest-versions does see the version as well, and it's trying to update it but it can't find the <version> element to update and it skips it because of that.

I believe that showing an update of a dependency which is not governed by any of the project files is incorrect; it can be updated by updating the parent or bom dependencies. Even so, there exists an integration test checking for just that, added by #291.

Marking as both bug and enhancement as it will probably need a feature toggle to preserve backward compatibility.

[andrzejj0]

Same thing is true about e.g. dependency-updates-report, which also outputs dependencies managed by parent outside of the reactor in this case, because the that Mojo, too, operates on the Maven interpolated model.

<dependencies>
    <dependency>
      <groupId>com.oracle.database.jdbc</groupId>
      <artifactId>ojdbc11</artifactId>
      <scope>compile</scope>
      <type>jar</type>
      <currentVersion>21.9.0.0</currentVersion>
      <lastVersion>23.6.0.24.10</lastVersion>
      <minors>
        <minor>21.10.0.0</minor>
        <minor>21.11.0.0</minor>
        <minor>21.12.0.0</minor>
        <minor>21.13.0.0</minor>
        <minor>21.14.0.0</minor>
        <minor>21.15.0.0</minor>
      </minors>
      <majors>
        <major>23.2.0.0</major>
        <major>23.3.0.23.09</major>
        <major>23.4.0.24.05</major>
        <major>23.5.0.24.07</major>
        <major>23.6.0.24.10</major>
      </majors>
      <status>minor available</status>
    </dependency>
  </dependencies>

[rmie]

IMHO it would be already helpful to add information about the origin of the issue, similar to what help:effective-pom -Dverbose does:

      <dependency>
        <groupId>com.oracle.database.jdbc</groupId>  <!-- org.springframework.boot:spring-boot-dependencies:3.3.4, line 1347 -->
        <artifactId>ojdbc11</artifactId>  <!-- org.springframework.boot:spring-boot-dependencies:3.3.4, line 1348 -->
        <version>21.9.0.0</version>  <!-- org.springframework.boot:spring-boot-dependencies:3.3.4, line 1349 -->
      </dependency>

From this, one would immediately know where to go to fix it.

[andrzejj0]

Very good idea.

[andrzejj0]

@slawekjaranowski do you think we should not show dependencies coming from parents outside of the reactor by default?

[rmie]

do you think we should not show dependencies coming from parents outside of the reactor by default?

@andrzejj0 I think that this is not a clear cut yes or no, but depends on the use case

• for audit, compliance, etc. perspective, users are probably interested in all outdated dependecies, as it is today
• from a day-to-day work perspective, users are probably only interested of what can be fixed while working on a project

[andrzejj0]

Okay. I'll make the option controlling this false by default (that is, the plugin will keep its old behaviour by default).

It's a good idea about showing the location of the dependency in those cases, much like what dependency:tree does, so I'll add that as well.

I'm currently trying to extract and use a common service for displaying dependencies, dependency reports, and perhaps even updates, which would make the behaviour there (and available options, like e.g. dependencyIncludes/excludes) consistent at once... but that's probably for a longer shot.