8000 Added support for dependency versions in buildscript.ext {} by JohannisK · Pull Request #5547 · openrewrite/rewrite · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Added support for dependency versions in buildscript.ext {} #5547

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Added support for dependency versions in buildscript.ext {} #5547

wants to merge 8 commits into from

Conversation

JohannisK
Copy link
Contributor
@JohannisK JohannisK commented Jun 3, 2025 •
edited
Loading

What's changed?

  • Added test for UpgradeDependencyVersion with variables in buildscript.ext {} when using dependencies.gradle
  • Added implementation
  • Added support for string concatenations when left is a dependency and right is a version variable

What's your motivation?

  • Although discouraged there are still usecases when buildscript.ext {} is used, and the use is not officially deprecated

@github-project-automation github-project-automation bot moved this to In Progress in OpenRewrite Jun 3, 2025
@JohannisK JohannisK self-assigned this Jun 3, 2025
@JohannisK JohannisK added the bug Something isn't working label Jun 3, 2025
@timtebeek timtebeek marked this pull request as draft June 3, 2025 08:43
@shanman190
Copy link
Contributor

I'm not sure if this test case captures a valid Gradle build. For some reason I think the buildscript.ext is treated separately from project.ext without overlap.

Secondarily, variable substitution was intentionally limited to the current build descriptor that contains a dependency that utilizes the variable (effectively enforcing scoping rules) and gradle.properties because otherwise we have no linkage to knowing that we're updating the correct variable or just some other random one that just so happens to have the same name.

@JohannisK
Copy link
Contributor Author
JohannisK commented Jun 4, 2025 •
edited
Loading

I'm not sure if this test case captures a valid Gradle build. For some reason I think the buildscript.ext is treated separately from project.ext without overlap.

Secondarily, variable substitution was intentionally limited to the current build descriptor that contains a dependency that utilizes the variable (effectively enforcing scoping rules) and gradle.properties because otherwise we have no linkage to knowing that we're updating the correct variable or just some other random one that just so happens to have the same name.

I'm not that big of a gradle expert, but what I found so far is that variables declared in buildscript.ext {} should apply to dependencies in dependencies.gradle. The reported issue also contained examples showing the scenario is used.

I could expand on the solution, by actually keeping track of files where dependencies are declared in the scanner (so I know implementation "com.google.guava:guava:${guavaVersion}" was declared in dependencies.gradle) and then retrace those steps when I encounter apply from: 'dependencies.gradle' in the build.gradle

@shanman190
Copy link
Contributor

Ok, so researched this a little bit more.

buildscript { // receiver = org.gradle.api.Project
  ext { // receiver = org.gradle.api.Project (extension = ext, implementation class = org.gradle.api.plugins.ExtraPropertiesExtension)
    guavaVersion = "29.0-jre" // receiver = org.gradle.api.plugins.ExtraPropertiesExtension
  }
}

So any of these properties are going to be project specific and the imported standalone script would have it's version be directly dependent upon the current project's state of their extension.

So as an illustration:

settings.gradle

include("projectA")
include("projectB")

projectA/build.gradle

ext {
  guavaVersion = "29.0-jre"
}

apply from: "dependencies.gradle"

projectB/build.gradle

ext {
  guavaVersion = "30.0-jre"
}

apply from: "dependencies.gradle"

The above project is valid, but each project would include a different version of Guava because the extra properties are evaluated individually within the context of the script application. This is one of the challenges with respect to global dataflow analysis in terms of Gradle scripts.

@JohannisK
Copy link
Contributor Author

@shanman190 , but doesn't that mean in this context we can safely update the version in the ext block?

@shanman190
Copy link
Contributor

It's probably ok. We just have to realize that we're tiptoeing into global analysis land here and that may come with some potential risks.

Some examples:

  • What repositories do you search when looking for a new version? Each project may declare a different set, in one repository a newer version may be available that isn't available in another project (honestly unlikely), etc.
  • Extra properties don't inherit from parent projects, so in the above example there are two distinct and independent dependency resolution contexts.
  • The cross section of preconditions only selecting part of the repository and the dependencies.gradle (or another included script) existing outside of that context.

@github-project-automation github-project-automation bot moved this from In Progress to Ready to Review in OpenRewrite Jun 24, 2025
JohannisK added 3 commits June 26, 2025 13:17
@JohannisK
Merge branch 'main' of github.com:openrewrite/rewrite into 1226-upgra…
d14480b 
…dedependencyversion-better-support-updating-versions-defined-in-buildscript-block
@JohannisK
Removed commented code
1b1b040
@JohannisK
Added extra test
f65386a
@JohannisK JohannisK marked this pull request as ready for review June 26, 2025 11:59
@JohannisK JohannisK changed the title Added test showing UpgradeDependencyVersion does not upgrade buildscript.ext {} when using dependencies.gradle Added support for dependency versions in buildscript.ext {} Jun 26, 2025
@JohannisK JohannisK requested a review from jkschneider June 26, 2025 13:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@shanman190 shanman190 shanman190 left review comments

@github-actions github-actions[bot] github-actions[bot] left review comments

@sambsnyd sambsnyd sambsnyd approved these changes

@jkschneider jkschneider Awaiting requested review from jkschneider

Assignees

@JohannisK JohannisK

Labels
bug Something isn't working
Projects
OpenRewrite
Status: Ready to Review
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@JohannisK @shanman190 @sambsnyd
0