Gradle 1.12 User Guide translation-Chapter 2. Sonar plug-in, gradlesonar

Gradle 1.12 User Guide translation-Chapter 2. Sonar plug-in, gradlesonar

This article is translated by a CSDN blog blogger. For other chapters, see:

Http://blog.csdn.net/column/details/gradle-translation.html

Please pay attention to the address on Github for translation projects:

Https://github.com/msdx/gradledoc/tree/1.12.

To view the bilingual documents directly, visit:

Http://gradledoc.qiniudn.com/1.12/userguide/userguide.html.

In addition, Android mobile users can browse documents through a program I wrote with the cache function. The current version 0.2.1 is compatible with android 2.2 and later. The address is as follows:

Http://www.wandoujia.com/apps/com.githang.gradledoc

It is not easy to translate. For more information, see the source of this article on the CSDN blog:

Http://blog.csdn.net/maosidiaoxian/article/details/46770471

For my translations of Gradle, refer to the project on Github and documents on the http://gradledoc.qiniudn.com. If any translation error is found, it will be updated in the above two places first. Due to time and energy problems, the translations published in the blog are basically not modified simultaneously.

Chapter 2. Sonar plug-in

You may want to use the new Sonar Runner plug-in to replace the current plug-in. This is especially because only the Sonar Runner plug-in supports Sonar 3.4 and later versions.

The Sonar plug-in provides integration with Sonar, a web-based code quality monitoring platform. This plug-in has been addedsonarAnalyzeTask is used to analyze which plug-in is applied to a project and a sub-project. The analysis results are stored in the Sonar database. This plug-in is based on Sonar Runner and requires Sonar 2.11 or a later version.

SonarAnalyzeA task is an independent task that requires explicit execution and does not depend on any other task. In addition to the source code, the task also analyzes the class files and test result files (if any ). To obtain the best results, we recommend that you run a complete build before analysis. In typical settings, an analysis is run on the build server every day.

35.1. Usage

The minimum requirement is that the Sonar plug-in must be configured to apply to this project.

Example 35.1. Configure the Sonar plug-in

build.gradle

apply plugin: "sonar"

Unless Sonar runs locally and has the default configuration, it is necessary to configure the Sonar server and database connection settings.

Example 35.2. Configure 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"    }}

Alternatively, you can set some or all connection settings from the command line (see section 35.6, "Configure Sonar settings from the command line ").

The Project setting determines how the Project will be analyzed. The default configuration is very suitable for analyzing standard Java projects and can be customized in many aspects.

Example 35.3. Configure Sonar project Settings

build.gradle

sonar    project        coberturaReportPath = file("$buildDir/cobertura.xml")    }}

In the preceding example,sonar,server,databaseAndprojectThe block is configured separatelySonarRootModel,SonarServer,SonarDatabaseAndSonarProjectType object. For more information, see their API documentation.

35.2. Analysis of Multi-Project Construction

The Sonar plug-in can analyze the hierarchy of the entire project at a time. It can generate a hierarchy chart on the Sonar web interface, which contains comprehensive indicators and can penetrate into sub-projects. At the same time, it is faster than analyzing each project separately.

To analyze the project hierarchy, you need to apply the Sonar plug-in to the top-level project of the hierarchy. Usually (but not necessarily) is the root project. In this projectsonarThe block configuration isSonarRootModelType object. It has all the global configurations, the most important server and database connection settings.

Example 35.4. Global configuration in 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 in the parent build script.

Example 35.5. configure a common project in a multi-project build

build.gradle

subprojects {    sonar        project            sourceEncoding = "UTF-8"        }    }}

In the sub-projectsonarThe block configuration isSonarProjectModelType object.

These Projects can also be configured separately. For example, SetskipThe property istrueTo prevent a project (and its sub-projects) from being analyzed. Skipped projects are not displayed on the Sonar web interface.

Example 35.6. Separate project configuration in multi-project build

build.gradle

project    sonar        project            skip = true        }    }}

Another typical project configuration is to configure the programming language for analysis. Note that Sonar can only analyze one language for each project.

Example 35.7. Configure language analysis

build.gradle

project    sonar        project            language = "groovy"        }    }}

When only one attribute is set at a time, the syntax of the equivalent attribute is more concise:

Example 35.8. Use attribute syntax

build.gradle

project(":project2").sonar.project.language = "groovy"

35.3. Analyze custom Source Sets

By default, the Sonar plug-in will analyzemainProduction source files in the source set, andtestSource files in source sets. Its analysis is independent of the source directory layout of the project. You can add additional source sets as needed.

Example 35.9. Analyze custom Source Sets

build.gradle

sonar.project {    sourceDirs += sourceSets.custom.allSource.srcDirs    testDirs += sourceSets.integTest.allSource.srcDirs}

35.4. Analyze non-Java languages

To analyze non-Java code, install the corresponding Sonar plug-in and set it accordingly.sonar.project.language:

Example 35.10. Analyze non-Java languages

build.gradle

sonar.project {    language = "grvy" // set language to Groovy}

As of Sonar 3.4, only one language can be analyzed for each project. However, in multi-project building, you can set different languages for different projects.

35.5. Set custom Sonar attributes

Eventually, most configurations are passed to the Sonar Code Analyzer in the form of a key-value pair called the Sonar attribute. In the API documentationSonarPropertyThe annotation shows how the attributes of the Object Model of the plug-in are mapped to the corresponding Sonar attributes. The Sonar plug-in provides hooks for post-processing before the Sonar attribute is passed to the Code Analyzer. The same hook can be used to add additional attributes without being overwritten by the object model of the plug-in.

For the global Sonar attribute, you can useSonarRootModelOnwithGlobalPropertiesHook:

Example 35.11. Set custom global attributes

build.gradle

sonar.withGlobalProperties { props ->    props["some.global.property"] = "some value"    // non-String values are automatically converted to Strings    props["other.global.property"] = ["foo", "bar", "baz"]}

For the Sonar attribute of each project, useSonarProjectOnwithProjectPropertiesHook:

Example 35.12. Set custom Project Properties

build.gradle

sonar.project.withProjectProperties { props ->    props["some.project.property"] = "some value"    // non-String values are automatically converted to Strings    props["other.global.property"] = ["foo", "bar", "baz"]}

The list of available Sonar attributes can be found in the Sonar document. Note: For most of these attributes, the object model of the Sonar plug-in has equivalent attributes and is not requiredwithGlobalPropertiesOrwithProjectProperties. For third-party Sonar plug-in configuration, see the plug-in documentation.

35.6. Configure Sonar settings from the command line

The following attributes can be either in the command line orsonarAnalyzeYou can set the parameters of a task in either of the following ways. The task parameter overwrites any value set in the build script.

• server.url
• database.url
• database.driverClassName
• database.username
• database.password
• showSql
• showSqlResults
• verbose
• forceAnalysis

The following is a complete example:

gradle sonarAnalyze --server.url=http://sonar.mycompany.com --database.password=myPassword --verbose

If you need to set other attributes from the command line, you can use the system attributes to do the following:

Example 35.13. Implement custom command line attributes

build.gradle

sonar.project {    language = System.getProperty("sonar.language", "java")}

However, remember that it is usually better to configure it in the build script and under the control of the Code.

35.7. Task

The Sonar plug-in adds the following tasks to the project.

Table 35.1. Sonar plug-in-task

Task Name	Dependent on	Type	Description
sonarAnalyze	-	sonarAnalyze	Analyze the project hierarchy and store the results in the Sonar database.