Scanner Ecosystem: CLI, Maven, Gradle, .NET, and Build Integration: Core Concepts and Mental Model

1. Current baseline and scope

Chapter 06 proved the generic analysis chain. Chapter 07 keeps that chain but changes the client-side owner. A Python or build-neutral repository can use Scanner CLI. A Maven project should normally use SonarScanner for Maven; Gradle has its plugin/task; MSBuild and dotnet projects use the .NET scanner's begin/build/end lifecycle. The server still receives an analysis report and creates a Compute Engine task.

2. Mental model: build ecosystem determines scanner entry point

flowchart TD
R[Repository + revision] --> B{Build ecosystem}
B -->|build-neutral| C[Scanner CLI]
B -->|Maven| M[Maven lifecycle + sonar plugin]
B -->|Gradle| G[Gradle tasks + sonar plugin]
B -->|MSBuild / dotnet| N[begin → build → end]
M --> X[Compiled/test/coverage context]
G --> X
N --> X
C --> A[Indexed files + analysis report]
X --> A
A --> U[Upload]
U --> CE[Compute Engine]
CE --> Q[Issues + measures + Quality Gate]

Scanner CLI starts from a filesystem/project configuration model. Maven and Gradle can derive properties from their build models and can coordinate Java bytecode and report locations. The .NET scanner modifies/observes the build between begin and end; running only an end command after an unrelated build is not equivalent.

3. State stores that move independently

4. Scanner selection rule

5. Runtime model: build JVM is not always scanner JVM

Current scanner generations support JRE auto-provisioning. That means the Java used by Maven or Gradle to run the build is not automatically proof of the Java runtime used by the scanner engine. Current Maven scanner documentation requires Maven 3.2.5+ and Java 21 when provisioning is not used, while Java 11+ can bootstrap current auto-provisioning. Current Gradle documentation similarly distinguishes normal Java requirements from the lower bootstrap requirement with auto-provisioning.

The .NET scanner no longer requires you to preinstall Java in the normal modern path because it provisions the scanner Java runtime. If provisioning is deliberately disabled or network policy prevents it, record the exact fallback runtime rather than copying an old “Java 17” tutorial.

6. Compiled context is part of the analysis input

Java analysis requires compiled bytecode. Maven and Gradle are good examples of why scanner choice belongs next to the build: mvn clean verify …:sonar or an appropriate Gradle build followed by sonar gives the scanner the compilation context produced by the same build. If you delete target/classes or point sonar.java.binaries at an empty/wrong directory, static analysis cannot infer the same semantic information from source text alone.

7. Scanner cache is reusable dependency state, not analysis truth

Scanners use a user-home cache, normally under ~/.sonar; SONAR_USER_HOME can relocate it. CI systems commonly cache this directory to avoid repeated analyzer/JRE downloads. Cache reuse improves speed but must not be treated as project evidence. Record scanner versions and effective inputs separately, and diagnose cache permission/corruption problems without deleting first-failure evidence blindly.

8. Read-only inventory before choosing a scanner

git status --short
git rev-parse HEAD
sonar-scanner --version || true
mvn -version || true
gradle --version || true
dotnet --info || true
find . -maxdepth 2 -type f   \( -name pom.xml -o -name build.gradle -o -name build.gradle.kts      -o -name '*.sln' -o -name '*.csproj' -o -name sonar-project.properties \) -print

Do not install a scanner until you know which build descriptor exists, which build tool owns compilation, and whether previous test/coverage reports are expected.

9. DevOps connection: pin the client path like any other build dependency

Scanner drift can change runtime requirements, indexing behavior, dependency resolution, telemetry, or compatibility even when the server is unchanged. A reviewable pipeline therefore records the project revision, build tool/version, scanner/plugin version, runtime/provisioning mode, report paths, task ID, and server release. A centrally “latest” scanner with no provenance is operationally weaker than a controlled update process.

Knowledge check

Official references and version notes

• SonarScanner CLI — build-neutral scanner usage, cache behavior, project base directory, and Docker notes.
• SonarScanner CLI 8.1.0.6389 — official release provenance.
• SonarScanner for Maven and release 5.7.0.6970.
• SonarScanner for Gradle and release 7.3.1.8318.
• SonarScanner for .NET usage and release 11.2.1.137242.
• Scanner environment general requirements and JRE auto-provisioning.
• Official scanner examples — recommended scanner choice by build ecosystem.
• Apache Maven downloads — Maven 3.9.16 is the current stable Maven baseline used in the Maven lab.