Sonar Gradle plugin should not use allprojects

Currently org.sonarqube uses allprojects, and it effectively forces users to configure everything from the root project.

It would be better if sonarqube plugin was split into several plugins:
a) “plugin for capturing individual results”
b) “plugin for uploading the data to sonar server”

It causes several inconveniences:

  1. allprojects is deprecated in Gradle as it breaks project isolation
  2. allprojects creates implicit configuration dependency order
  3. allprojects goes against Structuring Large Projects

Consider the plugin is split in several plugins:
org.sonarqube-base. It will create sonar extension and/or Gradle configurations so the plugins can declare the outputs
org.sonarqube-aggregate. It might create sonar task to upload the results the results, and it could declare Gradle configuration for specifying which projects should be aggregated.
For backward compatibility, you could add org.sonarqube plugin that will effectively apply org.sonarqube-aggregate to the root project and apply org.sonarqube-base to allprojects.

Then the users could apply the plugins accordingly (e.g. they could apply org.sonarqube-aggregate whenever they need), and they have sonar plugin/extension applied by accident.

Hi,

I don’t see what’s the advantage of creating 2 plugins. In the end there’s still a sonar extension and a sonar task that will always be applied together, right?

Let me put in a different way: currently sonar plugin assumes all projects are sonar-related.
However, some of my projects have nothing to do with sonar. For instance, the project collects licensing information: jmeter/src/licenses at master · apache/jmeter · GitHub
I do not want having sonar in that project.

At the same time, some of my projects do have sonar-related data.
For instance, if I add spotbugs, then I would like to add spotbugs reports to sonar.

Unfortunately, currently I have no way to declare ok, here's some data for sonar.
There’s no plugin to create sonar extension on the project.


Gradle’s best practice is to use composition for project configuration.
In other words, each project should list all the plugins it wants right in the plugins {...} section.
However, sonarqube-gradle-plugin breaks that pattern there’s no plugin I can apply into individual subprojects to declare “ok, I’ll have some data to send”.

See Designing Gradle plugins

You should consider using the same technique when designing your own plugins. You can develop both plugins within the same project and ship their compiled classes and identifiers with the same binary artifact. The following code example shows how to apply a plugin from another one, so-called plugin composition:

Having several plugins would make it way easier for the consumers to understand the way to configure the build.