Scanner Ecosystem: CLI, Maven, Gradle, .NET, and Build Integration: Configuration, Design Patterns, and Trade-Offs

1. Scanner ecosystem decision matrix

2. Pin scanner versions where reproducibility matters

Implicit plugin resolution is convenient but can move beneath a stable pipeline. For Maven, production CI can invoke the full coordinate with an explicit scanner plugin version. Gradle can pin org.sonarqube in the plugins block or version catalog. .NET global tools can be pinned by version during installation or managed by a tool manifest. Scanner CLI can be installed from a versioned distribution with checksum verification.

Central management is still useful: organizations may publish a tested scanner baseline and automated upgrade policy. The design failure is not “central” or “local”; it is unreviewed drift with no provenance or rollback.

3. Auto-provisioned JRE versus system Java

Auto-provisioning reduces the need to synchronize scanner Java across every runner. It also introduces a download/cache/network/trust dependency that must be observable. Highly controlled or disconnected environments may disable provisioning and provide an approved Java runtime instead. That choice increases responsibility: current scanner Java requirements must be tracked and upgraded intentionally.

4. Local versus CI execution

Moving analysis into CI does not change scanner semantics. CI adds checkout depth, workspace paths, caches, secret stores, network policy, artifact retention, and job status. A scanner that works locally can fail in CI because the checkout lacks blame history, the build output was not produced in that job, a cache is unwritable, or the server certificate/token is unavailable. Diagnose those as orchestration boundaries, not analyzer defects.

5. Test and coverage reports are imported evidence, not generated magically

Build-integrated scanners know where many build artifacts live, but coverage still comes from the appropriate coverage tool. For Java that may be JaCoCo XML; for .NET the format depends on the chosen test/coverage tooling. Record the command that produced the report, the report path, and its timestamp before analysis. A scanner warning that a report is missing is not fixed by inventing a path to a stale file.

6. .NET design pattern: preserve the lifecycle envelope

dotnet tool install --global dotnet-sonarscanner --version 11.2.1.137242
export SONAR_TOKEN='<process-secret>'
dotnet sonarscanner begin /k:"academy-dotnet" /d:sonar.host.url="http://127.0.0.1:9000" /d:sonar.token="$SONAR_TOKEN"
dotnet build Demo.sln --no-incremental
dotnet sonarscanner end /d:sonar.token="$SONAR_TOKEN"

The command illustrates lifecycle placement; the raw token must come from a protected process/secret store. Do not commit the example marker as a real credential. The build between begin/end is part of analysis capture.

7. Gradle design pattern: build context plus explicit task relationship

plugins {
    java
    id("org.sonarqube") version "7.3.1.8318"
}

Current documentation requires Java bytecode for Java analysis. Make the build/analysis ordering explicit in your pipeline rather than assuming the sonar task compiled everything you need. Record the wrapper/Gradle version, plugin version, Java runtime, and produced class directories.

8. Worked architecture choice

9. Edition and product boundaries

Scanner choice is generally independent of Community Build versus commercial Server editions: the same client ecosystem can target different SonarQube Server offerings subject to current compatibility and feature rules. Branch/PR decoration, advanced security, portfolio/application, and Data Center capabilities are separate edition/server concerns. SonarQube Cloud is a distinct hosted product; do not teach its defaults as if they were a self-managed Server deployment.

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.