Inspect versionless managed dependencies inside Maven profiles

[martinfrancois]

Suggested review order: 52 of 52 (Score: 0.5)
Review first: #8468

What's changed?

Adds 1 known-failing test to ManagedDependencyRequiresVersionTest that reproduces a coverage gap in DependencyManagementDependencyRequiresVersion: versionless dependencyManagement entries inside <profiles> are never removed, while identical top-level entries are. No recipe code changes.

The test is marked @Disabled so the suite stays green; removing the annotation shows the failure. I used @Disabled instead of @ExpectedToFail because junit-pioneer is not on the rewrite-maven test classpath. The class had 1 test before and has 2 tests with this change. With the annotation in place the class runs 2 tests with 1 skipped and 0 failures; with it removed, 2 tests run and 1 fails.

What's your motivation?

Recipe: org.openrewrite.maven.cleanup.DependencyManagementDependencyRequiresVersion.

The recipe removes managed dependencies that have no version. It only does this at the top level of the pom, not inside profiles. The new test uses one pom that holds both cases, so a single run shows the recipe visiting the file and skipping only the profile part.

Before

<project>
  <groupId>test</groupId>
  <artifactId>test</artifactId>
  <version>1.0-SNAPSHOT</version>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-databind</artifactId>
      </dependency>
    </dependencies>
  </dependencyManagement>
  <profiles>
    <profile>
      <id>example</id>
      <dependencyManagement>
        <dependencies>
          <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-core</artifactId>
          </dependency>
        </dependencies>
      </dependencyManagement>
    </profile>
  </profiles>
</project>

Actual after the recipe

Using current main, the top-level dependencyManagement block is removed, but the profile block is left exactly as it was, including the versionless jackson-core entry.

Expected after the recipe

The profile MUST retain its <id> and remove its versionless dependencyManagement entry, matching what the recipe already does at the top level.

The cause is that the no-argument MavenVisitor.isManagedDependencyTag() matches only /project/dependencyManagement/dependencies/dependency, so profile-scoped entries are never considered.

I found this while preparing #8445, which fixes a related defect in this recipe and discloses this inherited limitation in its description.

Anything in particular you'd like reviewers to focus on?

The judgment call. I think this is an improvement, not a bug: the recipe skips these entries rather than producing wrong output, and the recipe contract does not establish whether profile entries are in scope. One point against that reading: MavenVisitor already defines PROFILE_MANAGED_DEPENDENCY_MATCHER and uses it in the isManagedDependencyTag(groupId, artifactId) overload, so the no-argument overload is the odd one out. If you agree this should change, I would gladly prepare the fix. If this behavior is intended, feel free to close this and I know it is settled.

Any additional context

Pre-existing tests changed: None.

My open #8445 touches the same recipe; it does not fix this. A prior generic attempt to add profile-scoped dependency matchers to MavenVisitor, #4310, was closed unmerged. One caveat carried over from the top-level behavior and disclosed in #8445: entries that carry <exclusions> or <scope> are not fully inert, so removing them is not always a pure cleanup. This reproduction was prepared with AI assistance (Claude Code). I reviewed the tests and this description.

This draft adds a reproduction test only, so the first box stays unticked on purpose; I will complete it together with the fix if you want one. The formatter was run calibrated per file; I declined reindentation of untouched lines.

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've run ./gradlew build locally, and committed any resulting changes to recipes.csv
• I've formatted the lines I changed, without reformatting code I didn't touch