Gradle currently ships with support for SonarQube via the Sonar Plugin and the intended eventual replacement Sonar Runner Plugin. These plugins were developed by the Gradle Core development team.
In order to provide an even better experience for Gradle users wanting to leverage the SonarQube quality management platform, these plugins will soon be deprecated in favor of the new plugin developed by the good folks at SonarSource.
If you are using Gradle with SonarQube, please consider testing the new plugin and providing feedback to the plugin authors at this early stage.
On behalf of our SonarQube users… thank you SonarSource for investing in creating a more integrated Gradle & SonarQube experience.
If one of the plugin maintainers at SonarQube reads this:
I’m reading the documentation of the plugin, and noticed that the section “Shared configuration settings” recommends using a subprojects block, but shows an example not using subprojects.
There is also a missing “be” in “will taken into account” in the section “Setting properties from the Command Line”.
Can you please let me know if the sonarqube or sonarrunner plugins includes the test compile time dependencies on other subprojects in a multimodule project while running the test task from sonarqube.
Sorry if I posted this in a wrong section. I have separate question posted in more detail.
I am currently using the sonarqube plugin for gradle and have no idea where the source code is. Is it publically visible anywhere? How can i submit an issue to an issue tracker? The gradle plugins for sonar are a real mess to sort out which one is which.
@henryju Sonar runner plugin allowed jvm forkOptions for the runner process, couldn’t find an equivalent in the sonarqube plugin. Is there an option to do so?
@henryju If we change the Gradle JVM options they affect the entire build not just the sonarqube part. Are there any other alternatives? (build is mainly IBM Jdk 1.6)