Added test showing UpgradeDependencyVersion does not upgrade buildscript.ext {} when using dependencies.gradle

[JohannisK]

What's changed?

• Added test showing UpgradeDependencyVersion does not upgrade buildscript.ext {} when using dependencies.gradle

What's your motivation?

[shanman190]

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]

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]

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.