Sonar 2.2 Release Highlights: Filters, Plugin Classloaders, and Upgrade Notes

Originally published on 2010-07-19; fully revised and updated.

Sonar 2.2 was presented as a feature-focused release with two major additions: customizable homepage filters and independent plugin classloaders. This update is useful for engineers maintaining legacy Sonar installations, auditing historical plugin behavior, or understanding how Sonar’s extensibility model evolved.

What Sonar 2.2 changed at a glance

According to the original Sonar team announcement, version 2.2 centered on two key capabilities and also included broader maintenance work.

How homepage filters improved day-to-day triage

The filter system in Sonar 2.2 allowed teams to build focused views directly on the homepage. The original examples included:

• All projects
• Projects analyzed during the last 3 days
• Unit tests with longest execution time
• Classes in a project with coverage < 50% and complexity > 10
• Treemap of projects for a given Maven groupId
• My favourites (flagged resources such as projects, packages, and files)

Administrators could configure default homepage filters, while individual users could create personal filters for their own workflow.

flowchart TD
    A[Code analysis completes] --> B[Metrics are stored]
    B --> C[Homepage loads filters]
    C --> D[Filter tab shows selected resources]
    D --> E[User reviews hotspots]
    E --> F[Mark resources as favourites]
    F --> G[My favourites tab for quick return]
    C --> H[Admin sets default homepage filters]

Original screenshot links from the release announcement

• Homepage filters
• Display as treemap
• Create or edit filter (simple form)
• Create or edit filter (advanced form)
• Flag resources as favourites
• List favourites

Plugin classloaders in Sonar 2.2

The second headline feature was plugin isolation through independent classloaders. The stated benefit was that plugin authors were no longer limited to Sonar-provided libraries and could define their own dependencies.

Conceptual dependency example for a plugin build

The snippet below is a generic Maven illustration of plugin-local dependencies. Validate exact coordinates and plugin packaging details against archived Sonar 2.2 documentation before use.

<project>
  <dependencies>
    <dependency>
      <groupId>com.example</groupId>
      <artifactId>custom-metrics-lib</artifactId>
      <version>1.4.0</version>
    </dependency>
  </dependencies>
</project>Code language: HTML, XML (xml)

Original release resources

• Coding a plugin (see “How to use external dependencies?”)
• Upgrading plugins to version 2.2
• Sonar 2.2 release notes
• Downloads link referenced in the original post

Common pitfalls when using this historical release information

• Assuming 2010 documentation paths are still current in modern Sonar distributions.
• Expecting all legacy Codehaus and Skitch URLs to resolve without using web archives.
• Applying old plugin upgrade notes directly to newer major versions without migration checks.
• Treating historical feature behavior as unchanged in current releases.

Attribution preserved from the original announcement: Special thanks to contributors who provided patches, feedback, and support. — The Sonar team.

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.