I have created a sample spring boot project along with sonarqube gradle plugin in it .I have add all the needed properties like login token to sonar-project.properties.But while running gradle task I get exception of authentication
Gradle plugin added
plugins { id "org.sonarqube" version "2.6" }
Screenshot of project structure
I also suffered from this pain and my workaround was to parse the settings file and apply it:
sonarqube {
// this is silly but specifying the actual settings file is not supported
properties {
def props = new Properties()
file("sonar-project.properties").withInputStream { props.load(it) }
props.each {
property("${it.key}", "${it.value}")
}
}
}
Gradle analysis doesn't read sonar-project.properties. Instead, add those values to build.gradle as shown in the docs
sonarqube {
properties {
property "sonar.login", "xxxxxxxx"
}
}
Related
I am very excited about the incubating Gradle's version catalogs and have been experimenting with it. I’ve found that the information in my gradle/libs.versions.toml is accessible in the build.gradle.kts scripts for my app and utility-lib projects.
However, I am unable to use the content of the toml file for buildSrc/build.gradle.kts or the convention files.
The only way that I could build was to hard-code the dependencies into those files, as I did before the version catalog feature.
In the buildSrc folder, I created a settings.gradle.kts file and inserted the dependencyResolutionManagement code for versionCatalogs, which is pointing to the same file as for my app and utility-lib projects.
Based on the Gradle7 docs, it seems that sharing a version catalog with buildSrc and modules is possible… I’d appreciate a nudge into getting it to work with buildSrc, if possible.
Here is a simple sample project, which I created via gradle init: my-version-catalog
Thank you for your time and help,
Mike
With Gradle 7.3.3, it is possible. Note version catalogs are GA since Gradle 7.4
The code snippet assumes Gradle is at least 7.4, but if you need them prior that version, insert enableFeaturePreview("VERSION_CATALOGS") at the beginning of each settings.gradle.kts.
Using buildSrc
buildSrc/settings.gradle.kts
dependencyResolutionManagement {
versionCatalogs {
create("libs") {
from(files("../gradle/libs.versions.toml"))
}
}
}
buildSrc/build.gradle.kts
dependencies {
implementation(libs.gradleplugin.intellij) // <- the lib reference
}
You can even use the version catalog for plugins
gradle/libs.versions.toml
...
[plugins]
kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }
jetbrains-changelog = { id = "org.jetbrains.changelog", version.ref = "changelog-plugin" }
jetbrains-intellij = { id = "org.jetbrains.intellij", version.ref = "intellij-plugin" }
hierynomus-license = { id = "com.github.hierynomus.license", version.ref = "license-plugin" }
nebula-integtest = { id = "nebula.integtest", version.ref = "nebula-integtest-plugin" }
build.gradle.kts
plugins {
id("java")
alias(libs.plugins.kotlin.jvm)
alias(libs.plugins.nebula.integtest)
alias(libs.plugins.jetbrains.intellij)
alias(libs.plugins.jetbrains.changelog)
alias(libs.plugins.hierynomus.license)
}
Note for accessing the catalog within scripts, please refer to the below section, the trick is the same.
Using convention plugins and included build
In the main project include a the Gradle project that holds the convention plugins.
build.gradle.kts
includeBuild("convention-plugins") // here it's a subfolder
convention-plugins/settings.gradle.kts
dependencyResolutionManagement {
repositories {
gradlePluginPortal()
}
versionCatalogs {
create("libs") {
from(files("../gradle/libs.versions.toml"))
}
}
}
rootProject.name = "convention-plugins"
The trick to enable convention plugins to access the version catalog is split in two part, add an ugly implementation dependency that locate where the version catalog generated classes are located.
libs.javaClass.superclass.protectionDomain.codeSource.location
Then in the convention plugin refer to the libs extension via Project::the.
val libs = the<LibrariesForLibs>()
This is tracked by gradle/gradle#15383.
convention-plugins/build.gradle.kts
plugins {
`kotlin-dsl`
}
dependencies {
implementation(libs.gradleplugin.kotlin.jvm)
// https://github.com/gradle/gradle/issues/15383
implementation(files(libs.javaClass.superclass.protectionDomain.codeSource.location))
}
And in the actual convention plugin
import org.gradle.accessors.dm.LibrariesForLibs
plugins {
id("org.jetbrains.kotlin.jvm")
}
// https://github.com/gradle/gradle/issues/15383
val libs = the<LibrariesForLibs>()
dependencies {
detektPlugins(libs.bundles.kotlinStuff) // access catalog entries
}
The org.gradle.accessors.dm.LibrariesForLibs class is generated by gradle is somewhere in local gradle folder ./gradle/<version>/dependency-accessors/<hash>/classes
Quick note that older IntelliJ IDEA currently (2022.3) reports alias(libs.gradleplugin.thePlugin) as an error in the editor,
although the dependencies are correctly resolved.
This tracked by KTIJ-19369, the ticket indicates this is actually a bug in Gradle Kotlin DSL gradle/gradle#22797, and someone made a simple IntelliJ IDEA plugin to hide this error until resolved.
Brice, it looks like a can of worms to go down that path, particularly for my situation, where I'm trying to use a libs.version.toml file from an android project, but the custom plugin is of course from a java/kotlin project. I tried creating the libs file by hardwiring the path to the toml file in the custom plugin. It might work if both were java projects, but I never tried that since that's not what I'm after. The ideal solution would be for the plugin to use the libs file from the project it is applied to, but it looks like the version catalog needs to be created in the settings file, before you even have access to "Project", so that's why you would have to hardwire the path.
Short answer. No, but there are other techniques for a custom plugin to get project version data from the project it is applied to.
I want to apply a shared gradle file to my projects settings.gradle. The shared file is located in a jar which must be downloaded and extracted during the configuration phase. This is because is applies a plugin which must be applied in the configuration phase. I found this related question: How to share a common build.gradle via a repository? My preferred way is described in this answer: https://stackoverflow.com/a/39228611/987860
However, this appears to be working in build.gradle only. I tried to move the buildscript block to my settings.gradle.
settings.gradle
buildscript {
ext {
dependencyVersion = '0.1.2'
}
repositories {
maven {
credentials {
username 'user'
password 'password'
}
url 'https://my-private-maven-repo.com'
}
}
dependencies {
classpath "my.group:myartifact:$dependencyVersion"
}
dependencies {
def gradleScripts = new File(rootDir, '/build/gradle')
delete gradleScripts
def jars = configurations.classpath.files as List<File>
ant.unjar(src: jars.find { it.name.matches '.*myartifact.*' }, dest: gradleScripts) {
patternset {
include(name:'*.gradle')
}
}
}
}
apply from: new File(rootDir, '/build/gradle/myscript.gradle')
But this results in the following exception:
FAILURE: Build failed with an exception.
* Where:
Settings file 'settings.gradle' line: 24
* What went wrong:
A problem occurred evaluating settings 'journal'.
> Could not get unknown property 'ant' for object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Total time: 0.019 secs
Could not get unknown property 'ant' for object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
Is there any way to utilize ant int the confiuration phase before my settings.gradle is evaluated? I need to have the dependency downloaded and extractet before the to-be-downloaded file gets applied.
This is a really unusual way to do things. I'd really recommend not doing what you're trying to do because it'll make your build much slower than it should be. You're deleting build/gradle and extracting the contents of the plugin's jar on every build.
Everything inside a build.gradle (or settings.gradle) can be put into a plugin and distributed that way. You already have a jar that needs to be downloaded, so converting myscript.gradle into a plugin is very easy to roughly convert.
Put this in src/main/groovy/some/package/MyPlugin.groovy in the project that's producing the plugin jar already:
package some.package
import org.gradle.api.*
class MyPlugin implements Plugin<Project> {
void apply(Project project) {
project.with {
// contents of script
}
}
}
For plugins applied to settings.gradle:
package some.package
import org.gradle.api.*
class MyPlugin implements Plugin<Settings> {
void apply(Settings settings) {
settings.with {
// contents of script
}
}
}
Then you can just add the dependency to the plugin and use apply plugin: some.package.MyPlugin.
There are a lot of other advantages of developing/distributing plugins in this way. You can find more information on plugin development in the Gradle Guides.
Alternatively, if you absolutely must keep the separate .gradle script. If you can serve it separately (outside of the jar), you can do:
apply from: "http://example.com/some/url/myscript.gradle"
The downside with this is that it'll download the file on every build (this is fixed in Gradle 4.2).
We have a pretty standard web project using Java, which contains also some javascript code in the standard src/main/webapp folder. We are using Gradle 2.14 as our build tool.
We have just installed a brand new Sonarqube 6.0.1 on a fresh server, checked that both the Java and Javascript plugins are installed, and modified the build.gradle file as recommended on the Sonarqube documentation:
plugins {
id 'org.sonarqube' version '2.0.1'
}
sonarqube {
properties {
property 'sonar.projectName', 'Our-Project'
property 'sonar.projectKey', 'com.ourcompany:our-project'
}
}
This doesn't work as expected: the java code is analyzed correctly and we can browse the results on sonar, but the javascript code isn't analyzed.
What are we doing wrong? Thanks.
I have managed to fix our issues by adding this property inside the sonarqube block:
property 'sonar.sources', 'src/main'
Are you sure the sonar.sources is including the js files in the analysis? Can you add the module's gradle config? The file above looks like the app level gradle file. You should have at least one module for your app that also has a gradle file.
Android Studio Project Structure
You need to add the sources to the module's gradle file. Here's an example:
project(":app") {
sonarqube {
properties {
property "sonar.analysis.mode", "publish"
property "sonar.sources", "src/main/java"
property "sonar.java.binaries",
"build/intermediates/classes/debug"
property "sonar.junit.reportsPath",
"build/test-results/developDebug"
property "sonar.android.lint.report",
"build/outputs/lint-results-developDebug.xml"
property "sonar.test", "src/test/java"
}
}
}
I'm using Gradle 2.7 with the Gradle Liquibase plugin v 1.1.1. How do I run my changeSets as part of doing my normal build using
gradle build
? I currently have this in my build.gradle file ...
liquibase {
activities {
main {
File propsFile = new File("${project.rootDir}/src/main/resources/liquibase.properties")
Properties properties = new Properties()
properties.load(new FileInputStream(propsFile))
changeLogFile 'src/main/resources/db.changelog-1.0.xmlll'
url '${url}'
username '${username}'
password '${password}'
}
runList = main
}
}
However when I run the above command ("gradle build"), the above is not run. I know its not run because the username/password are incorrect and I have no change log file ending in ".xmlll". WHat else do I need to add to assure that hte plugin always attempts to execute the changeset?
You need to define a task dependency from build to update.
build.dependsOn update
To get task to run before your tests (assuming you didn't define a new one), you can do
test.dependsOn update
Ref:
Gradle task docs
You can define this in your gradle build file
apply plugin: 'liquibase'
dependencies {
classpath 'org.liquibase:liquibase-gradle-plugin:1.2.0'
}
liquibase {
activities {
main {
changeLogFile 'changelog.xml'
url 'jdbc:h2:db/liquibase_workshop;FILE_LOCK=NO'
username 'sa'
password ''
}
}
And then run this command
gradle update
Is there a way to exclude packages from SonarQube(instrumented by gradle + sonar-runner) coverage reports(generated by jacoco) without excluding them completely from the project ?
Below is what i tried so far:
Version information
SonarQube 4.5.1
Gradle 2.2.
Jacoco configuration
// JaCoCo test coverage configuration
tasks.withType(Test) { task ->
jacoco {
append = false
// excluded classes from coverage defined in above configuration
excludes = excludedClasses()
}
jacocoTestReport {
doFirst {
classDirectories = fileTree(dir: "${buildDir}/classes/main/").exclude(excludedClasses())
}
}
}
Sonarrunner configuration
Property setting to exclude package from Sonar analysis. Adding this to my configuration lead to the situation that the packages do not show-up at all in Sonar.
property 'sonar.exclusions', excludedClasses().join(',')
Property setting to exclude packages from jacoco. Setting this leads to the situation that packages are excluded from coverage analysis however show up having 0% which accumulates to bad total scores.
property 'sonar.jacoco.exclusions', excludedClasses().join(',')
I have managed to exclude particular packages from coverage reports by using sonar.coverage.exclusions property in sonar-project.properties. Property is described in official documentation
To combine #Mikalai's answer and #pavel's comment into something that's a bit easier to copy and paste:
To exclude a package or class from all Sonar checks (coverage, code smells, bugs etc), add the following to build.gradle:
sonarqube {
properties {
property 'sonar.exclusions', "**/com/some/package/**"
}
}
To exclude a package or class from only Sonar code coverage checks, add the following to build.gradle:
sonarqube {
properties {
property 'sonar.coverage.exclusions', "**/com/some/package/**"
}
}
To exclude res, assets, custom packages and auto generated classes from sonar code coverage for android project.
Create Exclusion list like below
exclusionList = [
//Res and Assets
"src/main/res/**/*.*",
"src/main/assets/**/*.*",
//Auto-Generated
'**/R.class',
'**/R$*.class',
'**/BuildConfig.*',
'**/*Manifest.*',
'android/**/*.*',
'androidx/**/*.*',
// excluded packages
**/com/<your-package-path>/**/*]
Provide the exclusion list to sonar coverage property
property 'sonar.coverage.exclusions', exclusionList
NOTE:
Keep the full path to exclude the full directory
**/* includes all the files and sub directories under the parent directory Refer Here
*Bean includes all the class names contains "Bean".
**/ starting with it covers the parent directories for the particular package.
Run Jacoco command and check sonar portal's coverage section after doing above changes.
If you are using Gradle 5+ with Kotlin DSL, you can exclude the files from coverage like this:
// configure the SonarQube plugin
sonarqube {
val exclusions = listOf(
"**/com/some/package/**",
"**/all/files/under/package/*",
"**/com/some/package/OneClass.kt"
)
// exclude the directories only from coverage (but not from other analysis)
// https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-gradle/
properties {
property("sonar.coverage.exclusions", exclusions)
}
}
exclude multiple module or class from Sonarqube. add below code to
build.gradle:
example :
package name= com.student.result.detail , com.customer.order ,com.student
sonarqube {
properties {
property 'sonar.exclusions', "**/com/student/result/details/**",
"**/com/customer/order/**",
"**/com/student/**";
}
}
This worked for me with gradle 6, sonarqube plugin 2.8
property "sonar.coverage.exclusions" , "**/com/some/package/entity/**/*," + "**/com/some/package/config/**/*,**/com/some/package/dto/**/*,**/com/some/package/dao/**/*"
NOTE: packages are comma separated but in a single string
Most of the answer I have seen here didn't work for me, resulting on the following error:
Execution failed for task ':sonarqube'.
> Could not find method property() for arguments [sonar.coverage.exclusions, **/package/path/Class1**, **/package/path/Class2**, **/package/path/Class3**, **/package/path/Class4**] on object of type org.sonarqube.gradle.SonarQubeProperties.
The reason is that sonar is asking for a string instead of several comma-separated strings as property value. So instead of:
sonarqube {
properties {
property 'sonar.exclusions', "**/com/student/result/details/**",
"**/com/customer/order/**",
"**/com/student/**";
}
}
The solution for me was:
sonarqube {
properties {
property 'sonar.exclusions', "**/com/student/result/details/**,"+
"**/com/customer/order/**,"+
"**/com/student/**";
}
}