I am setting up a new multi-module gradle project to be built in jenkins and trying to get sonarqube analysing it but I have struck several incompatibility issues which I haven't been able to resolve.
I am looking at using
the sonarqube plugin because our existing projects get a warning about the deprecation of sonar-runner:
The 'sonar-runner' plugin has been deprecated and is scheduled to be removed in Gradle 3.0. please use the official plugin from SonarQube (the docs).
gradle 3
this simple example from sonarqube https://github.com/SonarSource/sonar-examples/blob/master/projects/languages/java/gradle/java-gradle-simple/build.gradle
If I use gradle 3 I get this error: org.gradle.internal.jvm.Jvm.getRuntimeJar()Ljava/io/File;
If I use gradle 2.14 I get this error:
Caused by: java.io.IOException: Incompatible version 1007
This error in the past has been caused by an incompatibility between the jacoco and sonarqube plugins see JaCoCo SonarQube incompatible version 1007.
Which versions should I use?
FYI the release the SonarQube Scanner for Gradle 2.1 should happen very quickly and this version includes the support of Gradle 3.X. See https://jira.sonarsource.com/browse/SONARGRADL-16 which is already fixed.
You are not alone. I get the same issues as well. This works with gradle 2.12.
plugins {
id 'jacoco'
id 'java'
id "org.sonarqube" version "2.0.1"
}
Related
Grails version: 3.2.9
Gradle initial version: 3.4.1 (everything works fine with this version)
Gradle upgraded version:4.10.3
Plugin: org.grails.grails-gsp
When I run gradlew war after upgrading gradle version to 4.10.3 I start to get the following error during execution of compileGroovyPages task:
dashboard_gsp.groovy: 2: unable to resolve class com.abnd.CarStatusEnum
# line 2, column 1.
import com.abnd.CarStatusEnum
^
Location of class com.abnd.CarStatusEnum is src/main/groovy/com/abnd/CarStatusEnum in the same project where the build is being run and gradlew war task completes successfully with gradle version 3.4.1. However when I upgrade gradle version to 4.10.3 then I start to get this error. Same happens with gradle version 4.1.
1) Any clue what can be the problem ?
2) Is that a good idea to use gradle version 4.x.x or 5.x.x with grails version 3.x.x as with gradle 5.x.x I start to get even more issues as some grails plugins(like grails-gsp v3.3.2 which is latest stable version) use some features that have been deprecated in gradle 4.x.x and removed from gradle 5.x.x (see the error bellow)?
Failed to apply plugin [id 'org.grails.grails-gsp']
Could not get unknown property 'classesDir' for main classes of type org.gradle.api.internal.tasks.DefaultSourceSetOutput.
1) Any clue what can be the problem ?
Yes. The error message is a clue that the GSP compiler can't find the enum class. This is because our plugin isn't compatible with Gradle 4.10.3.
2) Is that a good idea to use gradle version 4.x.x or 5.x.x with
grails version 3.x.x
No. Those Gradle versions are not supported with the version of Grails you are using.
I hope that helps.
Since I updated my sonarqube server to 6.1 I'm getting this error in my gradle project.
I'm using sonar plugin latest version (2.2)
classpath("org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:2.2")
anyone knows how to solve it?
Thanks!
I resolved this problem by delete the cobertura jar file in the plugins folder. It seems sonarqube 6.1 does not support cobertura any more. because after i delete the file i can't find cobertura in the sonar plugin management page.
I have a java project with build system as Gradle. Recently we migrated to Java 8. After this migration sonarRunner task started failing with the following error :
05:10:51.823 INFO - Execute Findbugs 2.0.3...
05:10:56.502 INFO - Findbugs output report: /pathtoproject/build/sonar/findbugs-result.xml
The following errors occurred during analysis:
Unable to get XClass for java/util/function/BiConsumer
java.lang.ArrayIndexOutOfBoundsException: 1792
I started googling it and found out Findbugs 2.0.3 does not support I need to upgrade it and it was recommended that I should use Sonar server 5.x.x (my current sonar server is 5.4.x). I have some constraints yet I want my sonarRunner to be successful. Here are my constraints :
I can not upgrade the sonar server version (not in my hand)
Can not downgrade Java version.
I tried to search how to just upgrade the findbugs version in SonarRunner plugin that also I could not find. Please help me.
Most of the projects that I'm working with used Gradle 1.6 upto 2.3 with Java7 and I'm using Jacoco for code coverage.
Jenkins version is: 1.565.3 and 1.618 (I have two instances)
Jenkins's Jacoco Plugin version: 1.0.12
Gradle version: 2.3
Gradle's Jacoco Plugin version: 0.7.2.201409121644
Now in Gradle, there's a jacoco plugin (which provides jacocoTestReport task) and in Jenkins there's a Jacoco plugin which reads the exec files generated by running various tests and shows the reports on the Jenkins job's dashboard.
These reports are not showing up now if I'm using Java 8 with Gradle 2.0 upto 2.3 versions. Jenkins jobs builds and runs the analysis on Jacoco successfully but the reports is gone.
Have you seen this issue?
If you see this, it shows Coverage is gone and with the latest build all what is there is RED / no coverage.
Main dashboard:
Jacoco Plugin report (if you click on the above report on the job):
NOTE:
I have valid .exec files which shows valid code coverage if I use Gradle's jacocoTestReport task to generate the coverage in HTML format but the Jacoco plugin dashboard reports are not showing anything (just shows the headers only with no data/no coverage at all).
Reports generated by jacocoTestReport and Jacoco plugin in Jenkins generated valid output when I'm using Java7.
Report generated by Gradle's jacocoTestReport task using the same .exec files shows that jacoco* .exec files that I have are valid.
I figured out the cause why code coverage is not showing for Java 8 projects.
It's due to the incompatible version of Jenkins's Jacoco Plugin which works only with Java7 in your Jenkins instance. Try updating Jacoco plugin in Jenkins it to the latest version (1.0.15+).
Support to Java 8 was provided with version 1.0.15. Release notes of Jacoco plugin
Version 1.0.15 (Jun 11, 2014)
• Fix [JENKINS-20440] Inspector problem
• Fix [JENKINS-22716] - Update to JaCoCo 0.7.x to support Java 8
• Fix #40 - Project Dashboard chart having data cut off
Hence, jacoco plugin needs to be upgraded in your Jenkins.
Also, see Version info/Release info here: https://wiki.jenkins-ci.org/display/JENKINS/JaCoCo+Plugin
You'd notice there's a warning message (at this time) which might be resolved in upcoming versions (in few days).
Unfortunately JaCoCo 0.7.5 breaks compatibility to previous binary formats of the jacoco.exec files, the JaCoCo plugin is currently based on JaCoCo 0.7.4, thus you cannot use this plugin with projects which already use JaCoCo 0.7.5 or newer, please stick to 0.7.4 or lower for now until the plugin is updated
Can Gradle plugins for 1.11+ be expected to work for 2.+, and if not, how can one find out the state of compatibility?
Specifically, I have had success using Gradle 1.11 in a project spring-boot project. When upgrading to Gradle 2.2, I noticed that the spring-boot plugin does not seem to be available, although I haven't found any references to a particular Gradle version in the Spring Boot Gradle documentation (http://docs.spring.io/autorepo/docs/spring-boot/1.2.0.BUILD-SNAPSHOT/reference/html/build-tool-plugins-gradle-plugin.html).
Using Gradle 2.2, I get:
* What went wrong:
A problem occurred evaluating root project 'NN'.
> Failed to apply plugin [id 'spring-boot']
> A problem occurred configuring project ':webapp'.
> Extension of type 'SpringBootPluginExtension' does not exist. Currently registered extension types: [DefaultExtraPropertiesExtension, DefaultArtifactPub
licationSet_Decorated, ReportingExtension_Decorated, DefaultProjectSourceSet_Decorated, DefaultBinaryContainer_Decorated]
It depends on the particular plugin, and would ideally be tested/documented there. 1.x to 2.x was a big jump in terms of the Groovy version used by Gradle, which can cause compatibility issues for plugins implemented in Groovy. Also, 1.x plugins using deprecated or internal APIs may not work in 2.x.