We have written a custom language for SonarQube and under 7.2 we could supply the language we wanted used via a maven argument. sonar.language. Unfortunately this was deprecated in 7.7 and can no longer be used.
Our problem - we have two versions of the language (version 3 and version 4) - but we do not have a way to select this any more via a Maven execution. We do not want our users having to log into SonarQube and selecting the correct language or quality profile. We want to be able to send a Maven argument or setting like the old sonar.language.
In 7.9 we have now moved the 2 languages to be one language with 2 quality profiles - but only 1 can be default and this is causing issues for users.
Any suggestions on how to solve for this? We are already making use of Rule Categories for filtering rules and do not want to have to extend this another dimension.
Any suggestions? Other than editing the Maven SonarScanner?
In SonarQube API, the language concept is a bit misleading, since it is used at 2 different places that are not strictly speaking related (even if most of the time they are used in a consistent way). Let me try to sum up.
Plugins can declare a language (key, name, list of default file suffixes)
Rules have a language (defined in RulesDefinition). This is mostly a way to sort rules in the UI.
Files may have a language (optional). This is a way to classify files. Some metrics will be aggregated by language (ncloc by language). Default file suffixes are used to determine which files should be associated to which language. There are some scanner properties to override file suffixes patterns.
There is no constraint between rules and files. A Sensor can report an issue for rule A (language X) on a file that was detected as language Y. Or even on a file having no detected language.
Coming back to your use case, I don’t know how different are your two versions of the language, but if you look at how we did for Java, there is only one language, and one quality profile. There is a SonarJava specific scanner property (sonar.java.source) that is used to indicate to the analyzer what are the Java version of the source code. And then rules will adapt their behavior accordingly. For example you can have a rule suggesting to replace anonymous classes by a lambda activated in your quality profile, but if the code you are analyzing is targeting Java < 8, no issues will be reported.