Requesting advice for resolving conflict in SQ v9.3 between builtin text language and the community sonar-text-plugin

Hello and good day! I hope that you’re all weathering these uncertain times with a minimum of suffering. Per this recently posted Git issue a user of sonar-text-plugin is reporting that there’s a key name conflict between some new SQ functionality (Sonarqube version 9.3) and this community plugin. I’m this plugin’s maintainer and I’m hoping that you can provide me with some guidance on the simplest way to resolve this for our users.

Please be aware that the nature of this type of plugin is that users will have built up potentially extensive sets of custom rules. So if the solution involves updating the community plugin to deconflict its key name I’ll have to provide a way for them to preserve their custom rules.

Please provide any guidance that you can on the subject and I’ll use that info to guide my work to resolve this issue. Thanks in advance!


Thanks for the ping. I don’t think we were aware of the existence of your plugin before we introduced our own “text” analysis (or if we were previously, we’d lost sight of it). Otherwise, we’d have tried to coordinate first (or more probably picked a different key!).

So please accept my apology to you and your users.

This has been referred internally, so hopefully we’ll have a more official answer soon.


Hello @gjd6640,

The idea as you identified it, would be to change the plugin key to something else and to rely on a SonarQube API feature to migrate the rules to the new key.

We did that recently at SonarSource and moved the Java rules dealing with pom.xml files from the Java analyzer to the XML analyzer.

To achieve that, we relied on the annotation @DeprecatedRuleKey that is provided by Analyzer Common component. This is a library we used internally across all our analyzers. It’s not an public API so it’s subject to change without notice but still it’s open-source so you can decide to rely on it.
Here is an example of such migrated rule: sonar-xml/ at master · SonarSource/sonar-xml · GitHub

If you can’t use @DeprecatedRuleKey, then you can look at how it’s implemented and which SQ APIs are used in the background: sonar-analyzer-commons/ at master · SonarSource/sonar-analyzer-commons · GitHub


Hello. Thank you for taking the time to provide a detailed reply. I just acted on this and found that the collisions that were present were 1) the “Plugin-Key” value in the sonar-text-plugin jar’s manifest and 2) the “text” language defined in this plugin’s key. What I ended up doing was:

  1. Limit this plugin to be installable to only SQ v9.3 and up
  2. Removed the “text” language from this plugin (one is already provided in SQ v9.3)
  3. Changed the “Plugin-Key” property in the Jar manifest from “text” to “community-text”
  4. Left the “repository key” and the “language key” used for this plugin’s rule templates set to “text”

As info, when I tried to change the repo key to “community-text” to more completely isolate these two plugins I found that using “rule.addDeprecatedRuleKey(“text”, ruleKey);” did not result in the custom rules being moved over to the rule’s new repository. Had I continued down that path the upgrade procedure to go to v9.3 or higher would have been to back up any text language quality profiles prior to upgrading, search and replace that xml file, upgrade Sonarqube, and then restore it. That procedure would port the custom rules to the new repository key. There seems to be no need to do this right now though so I’m leaving that part alone to ease the lives of my users.

Thanks again!