It's by contract mandatory for each language plugin to be backward compatible with the latest SonarQube LTS version. The simple and safe way to do that is to depend upon the SonarQube LTS API. But with this approach, it might require up to one year before starting benefiting from new SQ API and providing some feedback on those new API. Based on Java reflection, it's possible to depend upon a new SQ API at compilation time and using or not the feature at runtime if the class/method doesn't exist but this strategy is both painful and error-prone.
The goal of this MMF is to provide a build-in mechanism allowing both :
- To use the latest SQ capabilities
- While providing a backward compatibility with LTS version
As APIs are always associated to a version number (javadoc tag @since), the easiest way to deal with capabilities is to check runtime version. For example if API is:
then the plugin, which compiles with API 5.5+, can do:
- provide a core component named org.sonar.api.SonarQubeVersion which allows to check runtime version of SonarQube
- sonar-packaging-maven-plugin must allow to override the manifest field "Sonar-Version", which is the minimal supported version of SonarQube. It is verified at runtime during server startup. By default it is the version of the dependency sonar-plugin-api.
Note that the same pattern should be applied to SonarLint Java API.