ChangeDependency renames a managed dependency into unmanaged coordinates, leaving it without a version

Open
  • Is something wrong?
#8,462 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

  • #8466 by @timtebeek — closed without merging

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
java
Domain
build-system

Research direction

Start at ChangeDependency, specifically org.openrewrite.maven.ChangeDependencyGroupIdAndArtifactId, and reproduce the issue with the supplied rewriteRun and pomXml example. Verify behavior when a dependency is managed only through an imported BOM and no newVersion is supplied; done when the resulting POM remains resolvable, while the separate stale MavenResolutionResult cause remains distinct.

Written by the indexing model from the issue text.

Description

bug maven recipe
What version of OpenRewrite are you using?

Latest main (reproduced at 560b40cc63).

What is the smallest, simplest way to reproduce the problem?

ChangeDependency / org.openrewrite.maven.ChangeDependencyGroupIdAndArtifactId renames a dependency that has no <version> of its own — its version comes from an imported BOM — into coordinates that the BOM does not manage. Because no newVersion is given, the recipe never considers the version at all, and the resulting POM does not resolve:

rewriteRun(
  spec -> spec.recipe(new ChangeDependencyGroupIdAndArtifactId(
    "com.squareup.okhttp3", "mockwebserver", null, "mockwebserver3", null, null)),
  pomXml(
    """
      <project>
          <groupId>com.mycompany.app</groupId>
          <artifactId>my-app</artifactId>
          <version>1</version>
          <dependencyManagement>
              <dependencies>
                  <dependency>
                      <groupId>org.springframework.boot</groupId>
                      <artifactId>spring-boot-dependencies</artifactId>
                      <version>2.7.18</version>
                      <type>pom</type>
                      <scope>import</scope>
                  </dependency>
              </dependencies>
          </dependencyManagement>
          <dependencies>
              <dependency>
                  <groupId>com.squareup.okhttp3</groupId>
                  <artifactId>mockwebserver</artifactId>
              </dependency>
          </dependencies>
      </project>
      """
  )
);
What did you expect to see?

Either an explicit <version> on the renamed dependency, or no change — anything that leaves the POM resolvable.

What did you see instead?
<!--~~(No version provided for direct dependency com.squareup.okhttp3:mockwebserver3:compile)~~>--><dependency>
    <groupId>com.squareup.okhttp3</groupId>
    <artifactId>mockwebserver3</artifactId>
</dependency>

Spring Boot 2.7 manages com.squareup.okhttp3:mockwebserver, but nothing manages mockwebserver3, so the rename orphans the version.

Are you interested in contributing a fix?

Yes — PR incoming.

Context

Seen in Moderne SaaS runs on repositories under finos (84 error markers with this signature across legend-sdlc, legend-depot and legend-shared) driven by Jakarta and Jackson migration recipes that call ChangeDependency without a newVersion, for jakarta.servlet:jakarta.servlet-api, jakarta.ws.rs:jakarta.ws.rs-api, jakarta.validation:jakarta.validation-api, jakarta.inject:jakarta.inject-api, io.swagger.core.v3:swagger-annotations and tools.jackson.core:jackson-{core,databind}.

Note that the same marker text also shows up for a different root cause, tracked separately: a child module whose parent's <dependencyManagement> is renamed keeps a stale MavenResolutionResult, so any later recipe that calls maybeUpdateModel() on that module re-resolves against the stale parent and reports this error even though the POMs on disk are consistent.

Dominant language
Java
Stars
3.9k
Forks
599
Avg merge
9h 38m
Merged PRs (30d)
557

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openrewrite/rewrite

All issues in openrewrite/rewrite

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.