Gradle ChangeDependency leaves an unversioned dependency when the new coordinates are unmanaged

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

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
java
Domain
build-system, tooling

Research direction

Start with ChangeDependencyTest#doNotPinWhenNotVersioned and compare it with Maven's ChangeDependencyGroupIdAndArtifactIdTest#managedToUnmanagedExternalizedDepMgmt. Read the GradleProject model and RemoveBomManagedDirectDependencies, then compare with ResolvedPom#getManagedVersion. Done means the Gradle recipe no longer leaves an unversioned renamed dependency when the new coordinates are unmanaged, while preserving managed dependencies and the documented override behavior.

Written by the indexing model from the issue text.

Description

bug gradle recipe
What version of OpenRewrite are you using?

Latest main (560b40cc63).

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

The Gradle org.openrewrite.gradle.ChangeDependency leaves a renamed dependency without a version whenever the declaration had no version of its own, even when a newVersion is supplied. This is currently asserted by ChangeDependencyTest#doNotPinWhenNotVersioned:

plugins {
  id 'java'
  id 'org.springframework.boot' version '2.6.1'
  id 'io.spring.dependency-management' version '1.0.11.RELEASE'
}
dependencies {
    runtimeOnly 'mysql:mysql-connector-java'   // -> 'com.mysql:mysql-connector-j'
}

Spring Boot 2.6.1 manages mysql:mysql-connector-java but not com.mysql:mysql-connector-j, so the resulting build script does not resolve. overrideManagedVersion is the documented escape hatch, and its own option description says "No check is done on the NEW dependency to verify if it is managed, it relies on whether the OLD dependency had a managed version."

  • The Maven side behaves the other way round: it writes an explicit version when it can tell that the new coordinates are unmanaged (ChangeDependencyGroupIdAndArtifactIdTest#managedToUnmanagedExternalizedDepMgmt), and after #8462 it declines to rename when it has no version to write.
What did you expect to see?

The Gradle recipe not producing a build script that cannot resolve, ideally matching the Maven decision.

What did you see instead?

An unversioned dependency on coordinates nothing manages.

The obstacle is that the GradleProject model does not record which versions come from dependency management, so "is the new GA managed?" cannot be answered the way ResolvedPom#getManagedVersion answers it for Maven. RemoveBomManagedDirectDependencies works around this by downloading each platform(...) POM and querying it, which covers platforms but not the io.spring.dependency-management plugin.

Are you interested in contributing a fix?
  • Not immediately — filing to track the Maven/Gradle asymmetry uncovered while fixing #8462.
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.