Retiring the magic `sonar:sonar` shorthand of the SonarScanner for Maven

EDIT 2026-05-12: Added alternative solution inserting the scanner in the plugin groups of your local settings.xml

TL;DR: To prevent any disruption in your analysis pipelines and keep on using mvn sonar:sonar, please make sure you have set the version the SonarScanner for Maven in your build configuration or on the command line when running your analysis before May 1st 2026.

Hello Maven friends,

The SonarScanner for Maven has long benefited from an automatic relocation mechanism. This mechanism enabled users to run analyses with the latest version of the plugin simply using the shorthand mvn sonar:sonar without any further configuration. While this automatic relocation mechanism has proven very useful to onboard new projects onto SonarQube, it should not be relied upon in production environments.

Why you should not rely on automatic relocation

Over the past few years, the automatic relocation has failed repeatedly, breaking CI pipelines at random times. Analyses would systematically fail with a variation of the following log message.

No plugin found for prefix 'sonar' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories ...

These disruptions could be easily prevented by versioning the plugin in your build configuration or on the command line when running your analysis. However, for the users who had no control over the CI pipeline configuration, the only possible solution was to wait for us to restore the mechanism.

Starting in June 2024, we began implementing changes to mitigate this recurring issue.

  1. We started emitting a warning message in your analysis logs when we detected that the version was not configured
  2. We revised our documentation to promote setting the version in your configuration
  3. We updated our project onboarding tutorials to remove any mention of the shorthand
  4. We set up a dedicated solution thread that should be easy to look for

On May 1st 2026, we will take the last action to prevent users from running into this issue by officially dropping the support of the relocation mechanism. In effect, we will no longer restore the mechanism when it fails after May 1st 2026.

How to ensure your analysis pipeline remains uninterrupted

You will need to cover 2 important steps:

  1. Check your analysis logs for warnings
  2. Lock down the full coordinates of the plugin

1. Check your analysis logs for warnings

First, inspect your analysis logs to see if a variation of the following message appears.

Using <the deprecated plugin invocation> instead of an explicit plugin version may introduce breaking analysis changes at an unwanted time. It is highly recommended to use an explicit version, e.g. '<explicit coordinates of the plugin you are using>'.

If you can see this message, the scanner detected usage without version configuration or using the latest version, and you will need to apply step 2 before May 1st.

If you do not see this message but your are unsure about your pipeline configuration, consider step 2 as you may want to lock the version of the scanner for greater stability.

2. Lock down the full coordinates of the plugin

One of three solutions, at three different levels, can be applied to ensure that your analysis runs using the full coordinates of the plugin.

Locking down plugin coordinates (and version) in your project build configuration

Locking down the plugin version in your build configuration gives you granular control enabling you to update the plugin as part of your regular dependency updates.

<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.sonarsource.scanner.maven</groupId>
        <artifactId>sonar-maven-plugin</artifactId>
        <!--
             The version tag below is optional but recommended to ensure 
             that upgrade to newer versions of the scanner are done deliberately.
        -->
        <version>version-of-the-scanner-here</version>
      </plugin>
    </plugins>
  </pluginManagement>
</build>
Using the full coordinates (and version) on the command line

You can use the full coordinates (and version) of the plugin when invoking the scanner.

mvn org.sonarsource.scanner.maven:sonar-maven-plugin:version-of-the-scanner-here:sonar
Adding the scanner to the plugin groups in your local Maven configuration

At the level you local Maven configuration, you can modify your settings.xml file to add the scanner as part of the plugin groups.

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0">
  <!--  ... -->
  <pluginGroups>
    <pluginGroup>org.sonarsource.scanner.maven</pluginGroup>
  </pluginGroups>
  <!--  ... -->
</settings>

This method ensures that your local configuration does not depend on the deprecated relocation mechanism, but unlike the 2 methods above it does not allow you to lock down the version.


As always, if you experience any issue following this guidance, please reach out.

Hi,

Thanks for the information. To make my teams are following the steps as mentioned here, can you please share where can we see the updated project onboarding tutorials as mentioned in the step 3 “We updated our project onboarding tutorials to remove any mention of the shorthand“.

Best regards,

Shanmugabharathi

Hi @shanmugabharathim,
The project onboarding tutorials are the pages you encounter when manually setting up the analysis of a Maven project on SQC, SQS or SQCB. The onboarding wizard will eventually provide you with an appropriate command line, after configuring the project key and analysis token, that you can use to run your first analysis.

The command line has been updated specifically to use the explicit coordinates of the maven plugin rather than using the old mvn sonar:sonar.

Best,

Dorian

Hello,

What exactly happens if we continue to call sonar:sonar after May 1st without specifying the version? We use it in some of our Azure DevOps pipelines and are wondering how urgently we need to make these changes.

Kind Regards,
Dirk

Hi @Dirk_Gabler,

Starting May 1st, we will no longer restore the automatic mechanism when it fails. In practice, this means that if your pipelines rely on it, you will have to fix your configuration as described above after the failure and you will experience preventable downtime.

Unfortunately, we cannot predict when the next failure will happen. For this reason, we strongly encourage you to verify your configuration before May 1st.

Best,

Dorian

Hi @Dorian_Burihabwa , thank you very much for the quick response.
Some of our AzureDevOps Pipelines use the SonarSource-Tasks provided like this:

steps:
  - task: SonarQubePrepare@7
...
  - task: Maven@4
      goals: verify
      sonarQubeRunAnalysis: true

  - task: SonarQubePublish@7
...

The sonarQubeRunAnalysis:true Parameter forces the maven call to be extended by this goal:

mvn  ... verify .. org.sonarsource.scanner.maven:sonar-maven-plugin:RELEASE:sonar

which ends up in this warning

[WARNING] Using RELEASE instead of an explicit plugin version may introduce breaking analysis changes at an unwanted time. It is highly recommended to use an explicit version

Is this the same or different issue. Will this be hit by the relocation problem also?

Kind regards,
Dirk

Hey @Dirk_Gabler,
Your pipelines should safe from the automatic relocation mechanism decommissioning as they eventually invoke the scanner with its full coordinates.

The log message is still relevant because you are still subject to scanner upgrades in between analyses but by the look of it, you should be ready for May 1st.

The post was updated today to add a third way of using the full coordinates of the plugin using plugin groups.