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:
allprojects is deprecated in Gradle as it breaks project isolation
allprojects creates implicit configuration dependency order
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.
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”.
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.
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:
Gradle is pushing for the Project Isolation feature and I am getting multiple issues related to this plugin, I think it is the last piece on our setup.