Plugin API versioning scheme in 8.1

SonarQube Server / Community Build Plugin Development
1

Hello,

I’m trying to update my plugin for 8.1 and I’ve noticed a couple of confusing changes about the plugin api artifact, which I don’t think were communicated anywhere in the docs, so I’m writing here hoping to get some clarification.

The first thing I’ve noticed is the versioning scheme in 8.1, which looks different from all the other versions published previously. There seem to be two releases of the 8.1 plugin api artifact, both published on the same day: 8.1.0.31237 and 8.1.0.31197:

Screenshot 2019-12-26 at 02.07.30

Was that intentional or just simply a mistake? If the former, does that mean a change in the versioning scheme used going forward? This format does not appear to be conformant with semantic versioning (the + character should be used to denote build metadata, e.g. 8.1.0+31237) - is that something you’re aware of and happy with? Is SonarQube server going to be able to parse a version defined by plugins in this format and determine correctly plugin compatibility given format isn’t a valid semver scheme?

What are the implications for plugin developers? I’m specifically referring to the Sonar-Version from the manifest, which defines the minimum version of supported SonarQube runtime. I’m assuming the earlier version needs to be targeted by plugin developers wanting to support 8.1, or was it released accidentally and SonarQube 8.1.0.31197 was never available for download?

The second thing I wanted to ask about is the new sonar-plugin-api-impl artifact, which seems to be necessary to be included as a test dependency in my plugin to get it compiled against 8.1. It took me a little bit of digging through the history on Github to figure out that I needed to include it since it contains all the internal packages which I’m making use of for testing purposes, such as the following (just to name a few):

  • org.sonar.api.batch.fs.internal.TestInputFileBuilder
  • org.sonar.api.batch.rule.internal.ActiveRulesBuilder
  • org.sonar.api.batch.rule.internal.NewActiveRule
  • org.sonar.api.batch.sensor.internal.DefaultSensorDescriptor
  • org.sonar.api.batch.sensor.internal.SensorContextTester
  • org.sonar.api.config.internal.MapSettings

Is that still the correct use to include this new module as a test dependency or do you have a replacement for the functionality provided by those internal packages somewhere else? It would be good to get this change documented for others as I was a little bit shocked by seeing ~250 compiler errors before discovering the internal packages were extracted to a separate module. It’s probably something that should be included either in the release notes, in a dedicated section for developers, or in the plugin API changes part of the docs.

Best regards,
Michael

2 Likes
3

Hi Michael,

Starting with 8.1, the version includes the build number. There are 2 artifacts because there was a mistake during the release process which forced us to do a second release. However, it has no impact in the API - both artifacts should be the same. You can simply pick the later one. 8.1.0.31197 was never available to download but you can also just set 8.1 as the minimum version supported.
We’ve been using this version scheme in other projects for a while now and we are happy with it.

About sonar-plugin-api-impl, it was introduced to hide internal classes from plugins. It will also make it easier to maintain different implementations of the API at runtime.
Adding it as a test dependency is a good strategy to use several implementation or factory classes that are in it.
I agree that we could’ve done a better job documenting this. I’ve created a ticket for us to improve the doc in the next release.