SCANCLI-223 Experiment with the Gradle Tooling API

[Seppli11]

---

Summary by Gitar

• New CLI functionality:
  • Added --dump-gradle-java-properties option to generate sonar-project.properties from Gradle builds.
  • Implemented GradleJavaPropertiesDumper to interface with the gradle-tooling-api and map project metadata.
• Project configuration:
  • Added gradle-tooling-api dependency in pom.xml.
• Documentation:
  • Included sonar-scanner-engine-issue-comparison.md detailing the semantic analysis gap between Gradle and property-dumped scans.
  • Added a sample scanner-engine-sonar-project.properties file.

_{This will update automatically on new commits.}

[hashicorp-vault-sonar-prod]

SCANCLI-223

[gitar-bot]

💡 Quality: Committed generated sample leaks developer home path/username

scanner-engine-sonar-project.properties is a 234-line generated artifact committed at the repository root. Every entry contains absolute, machine-specific paths from a developer's workstation (e.g. /home/sebastian.zumbrunn/code/... and /home/sebastian.zumbrunn/.gradle/caches/...), embedding a personal username and local Gradle cache layout. Generated/sample output with hardcoded local paths is not reproducible, can go stale, and unnecessarily exposes a developer's environment.

If this sample is needed for documentation, consider moving it under docs/ with sanitized/placeholder paths (e.g. /path/to/project), or omit it and reference the comparison doc instead. At minimum it should not live at the repo root.

_{Was this helpful? React with 👍 / 👎}

[gitar-bot]

⚠️ Edge Case: Dump mode triggers a real Gradle build with no version pinning

loadIdeaProject creates a GradleConnector with only forProjectDirectory(...) and then calls connection.getModel(IdeaProject.class). Without useGradleVersion(), useDistribution(), or useBuildDistribution(), the Tooling API resolves the Gradle distribution from the target project's wrapper (or downloads the connector's default), and configuring the IDEA model executes a full Gradle configuration phase on the user's machine. Consequences: (1) network access to download a Gradle distribution may be required, which can fail in offline/CI environments; (2) the resolved Gradle version may be incompatible with tooling-api 8.14.5 (the Tooling API only supports a bounded range of Gradle versions); (3) any build-script error surfaces as a wrapped IllegalStateException. For a CLI feature this behavior should be documented and ideally the supported Gradle version range validated up front. Since this is an experimental/draft feature this is acceptable for now but should be addressed before shipping.

Pin or validate the Gradle version and document the runtime Gradle execution requirement.:

// Optionally pin / validate the Gradle version to avoid surprises:
GradleConnector connector = GradleConnector.newConnector()
  .forProjectDirectory(projectRoot.toFile());
// e.g. .useGradleVersion("8.14.5") or document that the project's wrapper is used

• Apply fix

_{Check the box to apply the fix or reply for a change | Was this helpful? React with 👍 / 👎}

[gitar-bot]

💡 Quality: Experimental feature adds ~3MB and a new external repo to the CLI

Adding gradle-tooling-api pulls a sizeable dependency into the shipped distribution: the requireFilesSize enforcer rule was bumped from 9.2-9.3MB to 12.1-12.2MB, i.e. roughly +3MB on every published artifact (linux/windows/macos x64/aarch64). It also introduces a new required Maven repository (https://repo.gradle.org/gradle/libs-releases) to the build. For an experimental/draft feature, weighing this permanent size and build-dependency cost against the value is worth doing before merge — consider whether the dumper should ship in the main CLI artifact at all, or be a separate/optional module.

Re-evaluate bundling the tooling-api into the core CLI distribution.:

<!-- Consider scoping the gradle-tooling-api dependency to a separate artifact
     or feature module rather than bundling ~3MB into every CLI distribution. -->

• Apply fix

_{Check the box to apply the fix or reply for a change | Was this helpful? React with 👍 / 👎}

[gitar-bot]

💡 Quality: Dump mode bypasses skip handling and uses only CLI properties

In analyze(), the cli.isDumpGradleJavaProperties() branch returns early before conf.properties() and checkSkip(p) are evaluated, and it configures logging from cli.properties() only (ignoring global/project sonar-scanner.properties and environment settings). As a result sonar.scanner.skip is not honored in dump mode, and verbose/debug logging configured via property files (rather than -D/-X) will not take effect. This may be intentional for the POC, but if dump mode is meant to behave consistently with normal runs it should resolve the full property set (or at least honor the skip flag) before generating output.

Resolve full properties and honor skip/logging in dump mode.:

if (cli.isDumpGradleJavaProperties()) {
  Properties p = conf.properties();
  checkSkip(p);
  configureLogging(p);
  dumpGradleJavaProperties();
  displayExecutionResult(stats, SUCCESS);
  status = Exit.SUCCESS;
  return;
}

• Apply fix

_{Check the box to apply the fix or reply for a change | Was this helpful? React with 👍 / 👎}

[gitar-bot]

CI failed: The build failed because the 'gradle-tooling-api' dependency could not be resolved from the internal SonarSource repository.

Overview

The build failed during the dependency resolution phase of the Maven lifecycle. A single failure pattern was identified where a new dependency requirement could not be satisfied by the configured artifact repository.

Failures

Missing Dependency: gradle-tooling-api (confidence: high)

• Type: dependency
• Affected jobs: 82345651144
• Related to change: yes
• Root cause: The project attempts to pull org.gradle:gradle-tooling-api:8.14.5, which is not available in the internal SonarSource repository and not properly proxied.
• Suggested fix: Add the official Gradle repository (https://repo.gradle.org/gradle/libs-releases) to the project's pom.xml under a <repository> block or ensure the dependency is uploaded/proxied to the sonarsource Artifactory.

Summary

• Change-related failures: 1 (failed to resolve new project dependency).
• Infrastructure/flaky failures: 0
• Recommended action: Update the project's repository configuration in pom.xml to include the upstream Gradle repository to resolve the missing dependency.

Code Review ⚠️ Changes requested 1 resolved / 5 findings

Adds Gradle Java properties dump mode and documentation, but requires resolution for hardcoded developer paths in samples, unpinned Gradle build versions, and size budget violations.

⚠️ Edge Case: Dump mode triggers a real Gradle build with no version pinning

📄 src/main/java/org/sonarsource/scanner/cli/GradleJavaPropertiesDumper.java:145-154

loadIdeaProject creates a GradleConnector with only forProjectDirectory(...) and then calls connection.getModel(IdeaProject.class). Without useGradleVersion(), useDistribution(), or useBuildDistribution(), the Tooling API resolves the Gradle distribution from the target project's wrapper (or downloads the connector's default), and configuring the IDEA model executes a full Gradle configuration phase on the user's machine. Consequences: (1) network access to download a Gradle distribution may be required, which can fail in offline/CI environments; (2) the resolved Gradle version may be incompatible with tooling-api 8.14.5 (the Tooling API only supports a bounded range of Gradle versions); (3) any build-script error surfaces as a wrapped IllegalStateException. For a CLI feature this behavior should be documented and ideally the supported Gradle version range validated up front. Since this is an experimental/draft feature this is acceptable for now but should be addressed before shipping.

Pin or validate the Gradle version and document the runtime Gradle execution requirement.

// Optionally pin / validate the Gradle version to avoid surprises:
GradleConnector connector = GradleConnector.newConnector()
  .forProjectDirectory(projectRoot.toFile());
// e.g. .useGradleVersion("8.14.5") or document that the project's wrapper is used

💡 Quality: Committed generated sample leaks developer home path/username

📄 scanner-engine-sonar-project.properties:1-15

scanner-engine-sonar-project.properties is a 234-line generated artifact committed at the repository root. Every entry contains absolute, machine-specific paths from a developer's workstation (e.g. /home/sebastian.zumbrunn/code/... and /home/sebastian.zumbrunn/.gradle/caches/...), embedding a personal username and local Gradle cache layout. Generated/sample output with hardcoded local paths is not reproducible, can go stale, and unnecessarily exposes a developer's environment.

If this sample is needed for documentation, consider moving it under docs/ with sanitized/placeholder paths (e.g. /path/to/project), or omit it and reference the comparison doc instead. At minimum it should not live at the repo root.

💡 Quality: Experimental feature adds ~3MB and a new external repo to the CLI

📄 pom.xml:68 📄 pom.xml:71-79 📄 pom.xml:96-103 📄 pom.xml:258-265

Adding gradle-tooling-api pulls a sizeable dependency into the shipped distribution: the requireFilesSize enforcer rule was bumped from 9.2-9.3MB to 12.1-12.2MB, i.e. roughly +3MB on every published artifact (linux/windows/macos x64/aarch64). It also introduces a new required Maven repository (https://repo.gradle.org/gradle/libs-releases) to the build. For an experimental/draft feature, weighing this permanent size and build-dependency cost against the value is worth doing before merge — consider whether the dumper should ship in the main CLI artifact at all, or be a separate/optional module.

Re-evaluate bundling the tooling-api into the core CLI distribution.

<!-- Consider scoping the gradle-tooling-api dependency to a separate artifact
     or feature module rather than bundling ~3MB into every CLI distribution. -->

💡 Quality: Dump mode bypasses skip handling and uses only CLI properties

📄 src/main/java/org/sonarsource/scanner/cli/Main.java:80-86 📄 src/main/java/org/sonarsource/scanner/cli/Main.java:118-123

In analyze(), the cli.isDumpGradleJavaProperties() branch returns early before conf.properties() and checkSkip(p) are evaluated, and it configures logging from cli.properties() only (ignoring global/project sonar-scanner.properties and environment settings). As a result sonar.scanner.skip is not honored in dump mode, and verbose/debug logging configured via property files (rather than -D/-X) will not take effect. This may be intentional for the POC, but if dump mode is meant to behave consistently with normal runs it should resolve the full property set (or at least honor the skip flag) before generating output.

Resolve full properties and honor skip/logging in dump mode.

if (cli.isDumpGradleJavaProperties()) {
  Properties p = conf.properties();
  checkSkip(p);
  configureLogging(p);
  dumpGradleJavaProperties();
  displayExecutionResult(stats, SUCCESS);
  status = Exit.SUCCESS;
  return;
}

✅ 1 resolved

✅ Bug: Gradle tooling-api nightly version not on Maven Central

📄 pom.xml:88-92
The new dependency pins org.gradle:gradle-tooling-api:7.3-20210825160000+0000. That timestamped version is a Gradle nightly/snapshot build that is published to the Gradle repository (e.g. https://repo.gradle.org/gradle/libs-releases), not to Maven Central. No <repositories>/<pluginRepositories> section is declared in pom.xml, so Maven will only resolve against Central (plus inherited repos), and this artifact will fail to download — breaking the build for anyone without that nightly cached locally.

Fix: depend on a released Gradle Tooling API version that is available on Maven Central (e.g. 7.3, or a newer stable release), or add the Gradle releases repository to the POM so the nightly can resolve.

🤖 Prompt for agents

Code Review: Adds Gradle Java properties dump mode and documentation, but requires resolution for hardcoded developer paths in samples, unpinned Gradle build versions, and size budget violations.

1. 💡 Quality: Committed generated sample leaks developer home path/username
   Files: scanner-engine-sonar-project.properties:1-15

   `scanner-engine-sonar-project.properties` is a 234-line generated artifact committed at the repository root. Every entry contains absolute, machine-specific paths from a developer's workstation (e.g. `/home/sebastian.zumbrunn/code/...` and `/home/sebastian.zumbrunn/.gradle/caches/...`), embedding a personal username and local Gradle cache layout. Generated/sample output with hardcoded local paths is not reproducible, can go stale, and unnecessarily exposes a developer's environment.
   
   If this sample is needed for documentation, consider moving it under `docs/` with sanitized/placeholder paths (e.g. `/path/to/project`), or omit it and reference the comparison doc instead. At minimum it should not live at the repo root.

2. ⚠️ Edge Case: Dump mode triggers a real Gradle build with no version pinning
   Files: src/main/java/org/sonarsource/scanner/cli/GradleJavaPropertiesDumper.java:145-154

   `loadIdeaProject` creates a `GradleConnector` with only `forProjectDirectory(...)` and then calls `connection.getModel(IdeaProject.class)`. Without `useGradleVersion()`, `useDistribution()`, or `useBuildDistribution()`, the Tooling API resolves the Gradle distribution from the target project's wrapper (or downloads the connector's default), and configuring the IDEA model executes a full Gradle configuration phase on the user's machine. Consequences: (1) network access to download a Gradle distribution may be required, which can fail in offline/CI environments; (2) the resolved Gradle version may be incompatible with tooling-api 8.14.5 (the Tooling API only supports a bounded range of Gradle versions); (3) any build-script error surfaces as a wrapped `IllegalStateException`. For a CLI feature this behavior should be documented and ideally the supported Gradle version range validated up front. Since this is an experimental/draft feature this is acceptable for now but should be addressed before shipping.

   Fix (Pin or validate the Gradle version and document the runtime Gradle execution requirement.):
   // Optionally pin / validate the Gradle version to avoid surprises:
   GradleConnector connector = GradleConnector.newConnector()
     .forProjectDirectory(projectRoot.toFile());
   // e.g. .useGradleVersion("8.14.5") or document that the project's wrapper is used

3. 💡 Quality: Experimental feature adds ~3MB and a new external repo to the CLI
   Files: pom.xml:68, pom.xml:71-79, pom.xml:96-103, pom.xml:258-265

   Adding `gradle-tooling-api` pulls a sizeable dependency into the shipped distribution: the `requireFilesSize` enforcer rule was bumped from 9.2-9.3MB to 12.1-12.2MB, i.e. roughly +3MB on every published artifact (linux/windows/macos x64/aarch64). It also introduces a new required Maven repository (`https://repo.gradle.org/gradle/libs-releases`) to the build. For an experimental/draft feature, weighing this permanent size and build-dependency cost against the value is worth doing before merge — consider whether the dumper should ship in the main CLI artifact at all, or be a separate/optional module.

   Fix (Re-evaluate bundling the tooling-api into the core CLI distribution.):
   <!-- Consider scoping the gradle-tooling-api dependency to a separate artifact
        or feature module rather than bundling ~3MB into every CLI distribution. -->

4. 💡 Quality: Dump mode bypasses skip handling and uses only CLI properties
   Files: src/main/java/org/sonarsource/scanner/cli/Main.java:80-86, src/main/java/org/sonarsource/scanner/cli/Main.java:118-123

   In `analyze()`, the `cli.isDumpGradleJavaProperties()` branch returns early before `conf.properties()` and `checkSkip(p)` are evaluated, and it configures logging from `cli.properties()` only (ignoring global/project `sonar-scanner.properties` and environment settings). As a result `sonar.scanner.skip` is not honored in dump mode, and verbose/debug logging configured via property files (rather than `-D`/`-X`) will not take effect. This may be intentional for the POC, but if dump mode is meant to behave consistently with normal runs it should resolve the full property set (or at least honor the skip flag) before generating output.

   Fix (Resolve full properties and honor skip/logging in dump mode.):
   if (cli.isDumpGradleJavaProperties()) {
     Properties p = conf.properties();
     checkSkip(p);
     configureLogging(p);
     dumpGradleJavaProperties();
     displayExecutionResult(stats, SUCCESS);
     status = Exit.SUCCESS;
     return;
   }

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.
Unblock → Override a blocking verdict and allow merging.

Comment with these commands to change:

Auto-apply	Compact	Unblock
gitar auto-apply:on	gitar display:verbose	gitar unblock

_{Was this helpful? React with 👍 / 👎 | Gitar}