PLUGINAPI-189 Add mapper from Severities

[OrlovAlexander85]

For SonarSourcers:

Check before making the PR ready for review

• Create a JIRA ticket if the API is impacted
• Prefix the commit message with the ticket number
• Document the change in CHANGELOG.md
• When adding a new API:
  • Explain in the JavaDoc the purpose of the new API
  • Add a @since X.Y in the JavaDoc
• When deprecating an API:
  • Annotate the deprecated element with @Deprecated
  • Add a @deprecated since X.Y in the JavaDoc
  • Document the replacement in the JavaDoc (if any)
• When dropping an API:
  • Make sure it respects the deprecation policy
  • Bump the major version (breaking change)
• Make sure the tests adhere to the convention:
  • All test method names should use snake_case, for example: test_validate_input. It can also start with the methodName
• Make sure checks are green: build passes, Quality Gate is green
• Merge after getting approval by at least one member of the guild
  • If no review is made within 3 days, gently ping the reviewers
  • The guild member reviewing the code can explicitly request someone else (typically another guild member representing another team) to check the impact on the specific product
  • In some cases, the guild may deem it necessary that multiple or even all members approve a PR. This is more likely in complex changes or changes directly impacting all teams using the API.

For external contributors:

Please be aware that we are not actively looking for feature contributions. The truth is that it's extremely difficult for someone outside SonarSource to comply with our roadmap and expectations. Therefore, we typically only accept minor cosmetic changes and typo fixes. If you would like to see a new feature, please create a new thread in the forum "Suggest new features".

With that in mind, if you would like to submit a code contribution, make sure that you adhere to the following guidelines and all tests are passing:

Please explain your motives to contribute this change: what problem you are trying to fix, what improvement you are trying to make
Use the following formatting style: SonarSource/sonar-developer-toolset
Provide a unit test for any code you changed
If there is a JIRA ticket available, please make your commits and pull request start with the ticket ID (PLUGINAPI-XXXX)

Please note that opening the PR will notify all the squad members. Please make sure you keep it in DRAFT and mark it ready, when all the checks are green.

We will try to give you feedback on your contribution as quickly as possible.

Thank You! The SonarSource Team

[hashicorp-vault-sonar-prod]

PLUGINAPI-189

[sonar-review-alpha]

Summary

This PR adds two new static mapper methods to SeverityValues that bridge between the legacy rule severity system and the newer impact severity system:

• fromRuleSeverity(String) — maps rule severity strings (INFO, MINOR, MAJOR, CRITICAL, BLOCKER) to SeverityValues integers. Note the non-obvious mapping: MINOR→LOW and MAJOR→MEDIUM (not direct names).
• fromImpactSeverity(Severity) — maps impact severity enums to SeverityValues integers with a direct 1-to-1 mapping.

Both are marked @since 13.6 and throw IllegalArgumentException for unrecognized values. The API consolidates severity conversions in one place, reducing duplication across plugins.

What reviewers should know

Where to start: Review the mapping logic, especially fromRuleSeverity() — the MINOR→LOW and MAJOR→MEDIUM conversions are intentional but not immediately obvious. Look for unit tests to confirm the behavior is tested.

Key points for reviewers:

• Both methods are symmetric and handle all expected severity values
• The rule severity mapper accepts string constants from org.sonar.api.rule.Severity and maps them to legacy integer constants
• The impact severity mapper uses enums and expects matching names in both systems
• Both use exhaustive switch statements (consider checking if default case is adequate or if a more structured approach is needed)
• Verify that the @since 13.6 annotation is correct for the release this targets

Check against the author's checklist: The commit message prefix (PLUGINAPI-189) is present, and JavaDoc is properly formatted. Confirm CHANGELOG.md was updated per the PR template requirements.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[antoine-vinot-sonarsource]

I don't think this mapping should be part of the plugin api. IMO this is implementation detail and should be up to the platform.

[zipengwu]

I don't think this mapping should be part of the plugin api. IMO this is implementation detail and should be up to the platform.

There is one to one relationship between RuleSeverity and ImpactSeverity with the value of the new metrics. Without the explicit mapping, consumer of the new metrics won't know how to use it. Even they know how to use, they introduce duplication of code to do the same mapping in each product.

Moreover, we have already similar mapping ImpactMapper when we introduced MQR. @antoine-vinot-sonarsource

[antoine-vinot-sonarsource]

There is one to one relationship between RuleSeverity and ImpactSeverity with the value of the new metrics. Without the explicit mapping, consumer of the new metrics won't know how to use it. Even they know how to use, they introduce duplication of code to do the same mapping in each product.

Moreover, we have already similar mapping ImpactMapper when we introduced MQR. @antoine-vinot-sonarsource

@zipengwu
Fair enough, I think we can move forward with this for now to unblock you.
However, because we did it before for something else doesn't mean we were right.
The thing is, It should probably not be part of the plugin-api at all, since we (sonar) will be the only consumer of it.
As for duplication of it in our products (SQC, SQS, SonarLint etc..), it is not a problem that should be solved by the plugin-api.

[sonar-review-alpha]

LGTM! ✅

🗣️ Give feedback

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[zipengwu]

However, because we did it before for something else doesn't mean we were right.
The thing is, It should probably not be part of the plugin-api at all, since we (sonar) will be the only consumer of it.

Hi @antoine-vinot-sonarsource, isn't sonar-plugin-api public and used by all SonarQube plugins, including external ones?

Since we are introducing a new interface that directly relates to two existing ones, I believe providing an explicit mapping is the best way to help consumers understand the relationship between these contracts.