Marketplace, Plugins, Extension Risks, and Compatibility Management: Core Concepts and Mental Model

1. The practical problem: one JAR can change three execution planes

Chapter 25 moved from individual project evidence to governance views. Chapter 26 moves in the opposite direction: it examines a small artifact that can have a very large operational blast radius. A plugin is Java bytecode loaded by SonarQube. Depending on its extension points, it can participate in the web process, Compute Engine, or scanner bootstrap. That makes it part of both the software supply chain and the availability boundary of the SonarQube service.

Installing an analyzer because an old tutorial says “drop this JAR into the plugins folder” is therefore not equivalent to adding a static configuration file. The plugin may depend on a particular Sonar Plugin API, bundle third-party libraries, add rules or languages, change scanner downloads, alter Compute Engine behavior, expose web endpoints, or fail during startup. The correct unit of governance is the complete pair SonarQube core release + exact plugin artifact.

2. Mental model: artifact loading creates executable trust

Start from a known server build. Before an extension is introduced, record the server version, installed-plugin inventory, startup health, database/search health, and the projects that depend on the server. Then introduce one exact plugin artifact whose provenance and compatibility have already been checked. Only after a restart and clean startup may the new capability be considered available.

flowchart TD
  A[SonarQube core + Plugin API] --> B[Exact plugin JAR]
  P[Publisher/source + SHA-256 + license] --> B
  B --> C[extensions/plugins + restart]
  C --> D{Extension plane}
  D -->|Scanner| E[Analyzer / sensor behavior]
  D -->|Compute Engine| F[Post-processing behavior]
  D -->|Web| G[Administration / integration behavior]
  E --> H[Project result]
  F --> H
  G --> H
  H --> I[Availability / governance evidence]
  R[Preserved rollback artifact + baseline] --> C

The diagram is causal, not decorative. A capability cannot be attributed to the plugin unless the exact JAR was loaded by the intended server version and the server successfully returned to an operational state. Conversely, a startup failure must not be “fixed” by deleting logs or editing the database; preserve the artifact and startup evidence first.

3. What a plugin can extend

The Sonar Plugin API exposes extension points across the scanner, Compute Engine, and web application stacks. Scanner-side extensions can add sensors, rules, languages, or report processing. Compute Engine extensions participate after an analysis report is uploaded. Web-side extensions can add administrative or integration behavior. A plugin declares its entry point and metadata in its manifest and is loaded into an isolated classloader, but isolation does not eliminate operational risk: incompatible APIs or bundled libraries can still cause runtime failures.

4. Current installation model is edition-sensitive

5. Provenance packet before installation

A plugin governance record should be reproducible by a second operator. Store enough information to retrieve and identify the same bytes without trusting a mutable “latest” URL.

plugin_key: <manifest Plugin-Key>
plugin_name: <manifest Plugin-Name>
plugin_version: <exact immutable version>
artifact_file: <exact .jar name>
canonical_release_url: <publisher/repository release URL>
download_url: <immutable artifact URL>
sha256: <locally computed expected digest>
publisher_signature_or_attestation: <verified / not provided>
license: <SPDX/name + source>
source_repository: <canonical repository>
maintainer_owner: <team or publisher>
last_release_date: <date>
sonarqube_compatibility: <version-matrix/release evidence>
plugin_api_min_version: <manifest Sonar-Version when present>
transitive_dependency_review: <record / limitations>
rollback_artifact: <baseline copy or removal plan>
change_owner: <lab operator/team>

If the publisher supplies a cryptographic signature, provenance attestation, or SBOM, verify it and preserve the result. If none is supplied, say not provided; do not fabricate a signature claim. At minimum, pin the source and verify SHA-256 locally.

6. Compatibility has multiple layers

The Plugin version matrix answers one important question: which plugin version is declared compatible with a SonarQube release. The plugin manifest can also expose the plugin API minimum version. But compatibility is broader than either field. You still need to consider Java/runtime requirements, other plugin dependencies, the analyzer/language state of the server, license terms, and the upgrade path to the next SonarQube release.

7. Read-only inventory before touching extensions/plugins

# Disposable/local instance examples. No mutation yet.
curl -fsS http://localhost:9000/api/system/status
curl -fsS http://localhost:9000/api/server/version

# Filesystem inventory (ZIP/Docker paths differ by deployment):
ls -lah "$SONARQUBE_HOME/extensions/plugins"
sha256sum "$SONARQUBE_HOME"/extensions/plugins/*.jar 2>/dev/null || true

# Current API can expose installed plugin inventory. Authenticate if your
# instance forces authentication; never print the token itself.
curl -fsS -H "Authorization: Bearer $SONAR_API_TOKEN" \
  http://localhost:9000/api/plugins/installed \
  | python -m json.tool > evidence/plugins-before.json

# Preserve startup evidence before any extension change.
cp "$SONARQUBE_HOME/logs/web.log" evidence/web-before.log
cp "$SONARQUBE_HOME/logs/sonar.log" evidence/sonar-before.log

Do not remove an “old” JAR simply because its filename looks obsolete. First map each file to the server’s installed-plugin inventory and the owner/change record. A manually installed plugin may be the only provider of a language or rule population used by many projects.

8. Governance boundary: built-in first, extension only when justified

Before accepting plugin risk, ask whether the capability already exists in the current built-in analyzers, can be produced by a CI-side tool and imported as an external report, or can stay entirely outside the SonarQube server. Every server plugin increases the set of binaries that must be compatible during upgrades and available during startup. “Plugin available” is therefore not the same as “plugin should be installed.”

Knowledge check

Official references and version notes

• Community Build — Installing a plugin — Marketplace/manual paths, compatible JAR requirement, extensions/plugins, Docker/Kubernetes guidance, restart and uninstall behavior.
• Community Build — Using Marketplace — installed/compatible plugin discovery, internet/proxy behavior, Administer System requirement, pending install/update/uninstall and restart.
• Community Build — Plugin version matrix — current plugin-to-Community-Build compatibility table.
• Community Build — Plugin basics — Plugin API, scanner/Compute Engine/web extension points, manifest metadata, dependencies and Plugin-RequiredForLanguages.
• Community Build — Performing the update — install compatible third-party plugins for the target release instead of blindly copying old plugin folders.
• SonarQube Server — Installing a plugin — current commercial manual-install model and Data Center application-node consistency/maintenance rules.
• Sonar Plugin API repository — independent Plugin API release stream and SonarQube ↔ Plugin API compatibility mappings.
• Official SonarQube Docker image tags — exact 26.9.0.129388-community image used by the checkpoint.