Use explicit Gradle project dependency notation and test on Gradle 9.6.1

[jormundur00]

Fixes #900

What changed

This PR updates the Gradle plugin to stop using deprecated raw Project dependency notation when wiring its native compile-only configuration.

It also bumps the Gradle functional-test matrix to include 9.6.1 in the normal functionalTest lane so PR CI exercises the regression on a Gradle version that actually emits the deprecation.

Before this change, newer Gradle versions could report a deprecation warning for this dependency notation, and builds that treat warnings as failures could trip over it.

After this change, the plugin uses explicit project path notation instead, and the regression coverage runs on Gradle 9.6.1 with --warning-mode=fail.

Why

This removes a Gradle deprecation path and keeps the plugin compatible with stricter warning handling on newer Gradle versions.

The matrix bump is included because the new regression only becomes meaningful on Gradle 9.6+; without that lane, reduced PR CI would still run the class on 9.0.0 and would not prove the fix.

Example

Before:

On Gradle 9.6.1, running the functional test path with --warning-mode=fail could fail on the deprecated dependency notation path.

After:

The same path uses explicit project dependency notation and no longer triggers that deprecation warning.

Implementation summary

• Replace the deprecated raw Project dependency notation with explicit project path notation in the native compile-only configuration.
• Add a Gradle 9.6+ regression test that runs help --warning-mode=fail.
• Add 9.6.1 to the normal Gradle functional-test matrix, while leaving the config-cache matrix unchanged.
• Update the declared tested Gradle versions in the support-matrix spec.

Validation

• JAVA_HOME=$HOME/.sdkman/candidates/java/17.0.12-graal ./gradlew :native-gradle-plugin:functionalTest -DgradleVersion=9.6.1 --tests 'org.graalvm.buildtools.gradle.JavaApplicationFunctionalTest.does not use deprecated Project dependency notation'
• JAVA_HOME=$HOME/.sdkman/candidates/java/17.0.12-graal ./gradlew -PmatrixType=gradle :native-gradle-plugin:dumpFunctionalTestList

[sschuberth]

LGTM, any chance to get this officially review and merged?

[vjovanov]

Review

The production change looks correct and complete:

• dependencies.create(project) → dependencies.project(path: project.getPath()) is behaviorally equivalent: same self-project dependency with an absolute, build-local path, and nothing downstream depends on the declared dependency object's type (consumers only use resolved files/components).
• This was the only raw-Project notation site in the repo, so #900 is fully addressed.
• The map-based DependencyHandler.project() notation is the right choice for the plugin's Gradle 8.3+ floor — DependencyFactory#create(Project) is itself deprecated, and DependencyFactory#createProjectDependency(String) only exists since Gradle 9.5.

One issue with the test

The new regression test never exercises the regression in CI. The "Using a Project object as a dependency notation" nag was introduced in Gradle 9.6, but the CI functional-test matrix is ["current" (wrapper 8.3), "8.4", "8.14.2", "9.0.0"] (build-logic/.../github-actions-helper.gradle). No matrix version emits the nag, so the test passes identically with the old and the new code — it doesn't guard against reintroducing the bug. (The PR description's own repro had to pass -DgradleVersion=9.6.0-rc-1 explicitly.)

Suggestions:

1. Add a Gradle ≥ 9.6 version to the functional-test matrix so the test actually bites, and/or
2. Gate the test with the file's established @Requires-on-gradleVersion idiom (as used elsewhere in JavaApplicationFunctionalTest) to make explicit which versions it applies to.

One thing to be deliberate about: once the matrix includes ≥ 9.6, --warning-mode=fail will fail this test on any deprecation the plugin or the sample triggers on that version, not just this one.

Other angles checked and found fine: config-cache double-run (first uncached run still catches the nag), subproject path resolution (getPath() is absolute; multi-project-with-tests covers subprojects), and the Collections.singletonMap / tasks { succeeded ':help' } style, which matches existing conventions.

[jormundur00]

Replying to #903 (review)

Addressed this.

I added 9.6.1 to the normal Gradle functional-test matrix, left the config-cache matrix unchanged, and gated the regression in JavaApplicationFunctionalTest to Gradle >= 9.6 so the applicable version range is explicit.

I also updated the support-matrix spec to include the added tested Gradle version.

The latest PR CI for commit 4664016b79c5d8f8a48e9c79f2e3435ba812dae3 ran the JavaApplicationFunctionalTest lane on Gradle 9.6.1 successfully, so the regression is now exercised in PR CI.