Table 33.2. PMD plugin - additional task dependencies
Task name |
Depends on |
check |
All PMD tasks, including pmdMain and pmdTest. |
33.3. Dependency management
The PMD plugin adds the following dependency configurations:
Table 33.3. PMD plugin - dependency configurations
Name Meaning
pmd |
The PMD libraries to use |
33.4. Configuration
See PmdExtension.
Page 184 of 343
34
The Sonar Plugin
The Sonar plugin provides integration with Sonar, a web-based platform for monitoring code quality. The plugin adds a sonarAnalyze task that analyzes the project to which the plugin is applied and its subprojects. The results are stored in the Sonar database. The plugin requires Sonar 2.9 or higher.
The sonarAnalyze task is a standalone task that needs to be executed explicitly and doesn' depend on any other tasks. Apart from source code, the task also analyzes class files and test result files (if available). For best results, it is therefore recommended to run a full build before the analysis. In a typical setup, analysis would be performed once per day on a build server.
34.1. Usage
At a minimum, the Sonar plugin has to be applied to the project.
Example 34.1. Applying the Sonar plugin
build.gradle
apply plugin: "sonar"
Unless Sonar is run locally and with default settings, it is also necessary to configure connection settings for the Sonar server and database.
Page 185 of 343
Example 34.2. Configuring Sonar connection settings
build.gradle
sonar { server {
url = "http://my.server.com"
}
database {
url = "jdbc:mysql://my.server.com/sonar" driverClassName = "com.mysql.jdbc.Driver" username = "Fred Flintstone"
password = "very clever"
}
}
Project settings determine how the project is going to be analyzed. The default configuration works well for analyzing standard Java projects and can be customized in many ways.
Example 34.3. Configuring Sonar project settings
build.gradle
sonar { project {
coberturaReportPath = file("$buildDir/cobertura.xml")
}
}
The sonar, server, database, and project blocks in the examples above configure objects of type SonarRootModel, SonarServer, SonarDatabase, and SonarProject, respectively.
See their API documentation for further information.
34.2. Analyzing Multi-Project Builds
The Sonar plugin is capable of analyzing a whole project hierarchy at once. This yields a hierarchical view in the Sonar web interface with aggregated metrics and the ability to drill down into subprojects. It is also faster and less likely to run into out-of-memory problems than analyzing each project separately.
To analyze a project hierarchy, the Sonar plugin needs to be applied to the top-most project of the hierarchy. Typically (but not necessarily) this will be the root project. The sonar block in that project configures an object of type SonarRootModel. It holds all global configuration, most importantly server and database connection settings.
Page 186 of 343
Example 34.4. Global configuration in a multi-project build
build.gradle
apply plugin: "sonar"
sonar { server {
url = "http://my.server.com"
}
database {
url = "jdbc:mysql://my.server.com/sonar" driverClassName = "com.mysql.jdbc.Driver" username = "Fred Flintstone"
password = "very clever"
}
}
Each project in the hierarchy has its own project configuration. Common values can be set from a parent build script.
Example 34.5. Common project configuration in a multi-project build
build.gradle
subprojects { sonar {
project {
sourceEncoding = "UTF-8"
}
}
}
The sonar block in a subproject configures an object of type SonarProjectModel.
Projects can also be configured individually. For example, setting the skip property to true prevents a project (and its subprojects) from being analyzed. Skipped projects will not be displayed in the Sonar web interface.
Example 34.6. Individual project configuration in a multi-project build
build.gradle
project(":project1") { sonar {
project {
skip = true
}
}
}
Another typical per-project configuration is the programming language to be analyzed. Note that Sonar can only analyze one language per project.
Page 187 of 343