fix(gradle-plugin): replace usages of deprecated methods

[sergej-koscejev]

LenientConfiguration#getArtifacts(Spec) and BuildIdentifier#isCurrentBuild() were deprecated in Gradle 8 and removed in Gradle 9. Rewrite their usages to support Gradle 9.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 57.78%. Comparing base (305488d) to head (04818fc).
⚠️ Report is 7 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main   #11399   +/-   ##
=========================================
  Coverage     57.78%   57.78%           
  Complexity     1711     1711           
=========================================
  Files           347      347           
  Lines         12904    12904           
  Branches       1238     1238           
=========================================
  Hits           7456     7456           
  Misses         5000     5000           
  Partials        448      448           

Flag	Coverage Δ
test-ubuntu-24.04	42.51% <ø> (ø)
test-windows-2025	42.48% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[sergej-koscejev]

Can somebody please approve the workflows? I believe I fixed the test failures.

[sschuberth]

Somewhat related: I believe we haven't formally decided about the oldest Gradle version we'd want to support with GradleInspector. It more was like a best-effort approach so far. Looking at this, should we now formalize that we only support Gradle 7 and onward?

If we decide to go even further down, like Gradle 6.7 (first version with toolchain support) or even 5.0 (first version with Kotlin DSL support), we should add these version here. But I'd do so only if it doesn't cost us much in terms of code changes right now.

Options, @oss-review-toolkit/core-devs?

[sschuberth]

about the oldest Gradle version we'd want to support with GradleInspector

Oh, I just realized this PR is about the Gradle analyzer, not the GradleInspector one.

@sergej-koscejev, is there a specific reason why you are using the legacy Gradle analyzer instead of GradleInspector?

[sergej-koscejev]

Hmm, I think I got confused and thought that this code is used by both analyzers. I have re-checked now on my Gradle 9 project and realized my mistake, it seems to work with gradle-inspector so far.

[sschuberth]

In any case, I believe your changes are good for anyone who's still stuck with the Gradle analyzer, so I think we should merge them once there are no more findings.

[sschuberth]

GradleVersionFunTest fails for Gradle version 7.5.1 because the cached / pre-compiled init script was compiled with a too recent version of Java. I'll think about a solution.

[sergej-koscejev]

GradleVersionFunTest fails for Gradle version 7.5.1 because the cached / pre-compiled init script was compiled with a too recent version of Java. I'll think about a solution.

This confused me because with Gradle version null (7.5.1) the test is the same as the "Project dependencies are detected correctly" test in GradleLibraryFunTest. Why does that one work but this one doesn't? Is there some reuse/caching happening between the tests behind the scenes?

[sschuberth]

Is there some reuse/caching happening between the tests behind the scenes?

It seems so, yes, although even then I currently don't understand why this happens, as all Gradle tests I've checked explicitly use Java 17, but class file version 65 belongs to Java 21.

Anyway, let me work on some improvements to isolate things, and me take over your PR; I'll make some minor changes and rebase on top of those upcoming changes.