Sonar Maven Plugin 1.0-beta-2: What Changed for Archiva/Nexus-Based Builds

If you maintain older Maven + Sonar build pipelines, this 2010 update is important: Sonar Maven Plugin 1.0-beta-2 reduced extra repository-manager setup compared with beta-1. This guide summarizes the confirmed changes, shows the beta-1 vs beta-2 flow, and provides practical legacy command/config examples.

Originally published on 2010-09-14; fully revised and updated.

Original announcement: Sonar team released Sonar Maven Plugin 1.0-beta-2. The source post is brief, so this rewrite focuses on the explicit facts provided there and practical interpretation for legacy environments.

What changed in Sonar Maven Plugin 1.0-beta-2

• The Sonar team announced Sonar Maven Plugin 1.0-beta-2.
• The release aimed to make configuration easier when using repository managers such as Archiva or Nexus.
• Compared with beta-1, the post states that no additional settings were required anymore for that scenario.
• This improvement requires Sonar 2.2 or newer.
• When used with Sonar 2.1 or older, the improvement is automatically disabled.
• Upgrade behavior should be automatic when using the shortcut command mvn sonar:sonar or the Hudson plugin.

Beta-1 vs beta-2 behavior at a glance

Compatibility and execution flow

flowchart TD
    A[Start analysis with mvn sonar:sonar] --> B{Plugin path}
    B -- beta-1 style --> C[Extra repo config often needed]
    B -- beta-2 style --> D[No extra repo settings for this case]
    C --> E{Sonar 2.2 or newer}
    D --> E
    E -- yes --> F[Improvement active]
    E -- no --> G[Improvement disabled]
    F --> H[Analysis continues]
    G --> H

Legacy command and configuration examples

Run analysis using the shortcut

mvn sonar:sonarCode language: CSS (css)

The original post says upgrade behavior should be automatic when this shortcut is used.

Example of the kind of extra Maven mirror setup beta-1 often required

The source does not publish exact XML snippets. The following is an illustrative pattern of mirror configuration that teams commonly used in locked-down environments with repository managers:

<settings>
  <mirrors>
    <mirror>
      <id>company-repo</id>
      <mirrorOf>*</mirrorOf>
      <url>https://repo.example.com/maven2</url>
    </mirror>
  </mirrors>
</settings>Code language: HTML, XML (xml)

Simple validation checks in CI logs

• Confirm the build still runs with mvn sonar:sonar.
• Verify plugin resolution is happening through your repository manager path.
• Confirm Sonar server version is 2.2 or newer if you expect the beta-2 improvement to apply.
• If running Sonar 2.1 or older, expect fallback behavior (improvement disabled).

Best practices for maintaining this legacy setup

• Treat this release note as historical behavior; verify details against archived Sonar and plugin docs used in your environment.
• Document whether your pipeline still depends on old mirror/repository workarounds.
• Keep Maven settings and repository-manager policy in source-controlled infrastructure docs.
• When modernizing, test in a staging CI pipeline before changing repository resolution behavior.

Note: the original page also contains a YouTube API error message and a link to a video about API key setup (YouTube link), which appears unrelated to the Sonar plugin release details.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.