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.

1 Like

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: https://github.com/apache/jmeter/tree/master/src/licenses
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.

As I mentioned in other issue, using allprojects and subprojects break project isolation feature.

Hello @Vladimir_Sitnikov,

Thanks for the message and sorry that it took us so long to answer. We are aware of this issue. I understand your point and I understand why it initially was designed like this. I agree that we should reconsider the usage of allprojects, however, it will mean some breaking changes for our users, which we should also take into account.

Unfortunately, at the moment working on the subject is not our priority for this year, so I can’t guarantee this is going to happen soon. So I’ve created a ticket and noted that we should discuss this subject in the squad and find a proper solution. Here is the ticket:

https://sonarsource.atlassian.net/browse/SONARGRADL-129

Best,
Margarita

1 Like