I'm using a clone of an app which uses FindBugs, PMD, CheckStyle plugins.
But now, i've made some changes which makes minimum Gradle version to 6.5 and now i'm getting this error:
Plugin with id 'findbugs' not found.
As i read, the findbugs is deprecated for gradle 5.0+ .
Now, how can i remove the usage of these 3 plugins in this clone? Or how can i replace it(i think SpotBugs is the new version of it!)
Or how to solve this error?
Remove Findbugs and Add Spotbugs in your project.
You don't need to remove PMD and CheckStyle. They are working perfectly.
Only change is of Findbugs.
Related
i have configure my project on android studio thats use "Lombok" Plugin, i have download Lombok plugin on my IDE Android Studio, i've add compileOnly 'org.projectlombok:lombok:1.18.6', implementation 'javax.annotation:javax.annotation-api:1.3.2'and annotationProcessor 'org.projectlombok:lombok:1.18.6'...even adding it on my default config build graddle app
javaCompileOptions {
annotationProcessorOptions {
includeCompileClasspath true
}
}
but it still showing message "Annotation processing seems to be disabled for the project "OptimalRouteFinder". But lombok is on classpath.For the lombok plugin to function correctly, please enable it under bla bla bla"
What i have to do?
Go to File -> Other Settings -> Settings for New Project.
Next, go to (Build, Execution, Deployment) -> Compiler -> Annotation Processors and hit [x] Enable annotaion processing
This is an issue running in circles. Setting only as Dennis described does not resolve the issue. Accompanying it by replacing 'compileOnly' with 'provided' in the build.gradle makes the warning go away, but Android Studio then complains that 'provided' is deprecated and replaced with 'compileOnly'. I guess I have to ignore the latter warning, then.
+++++++++
Sorry, with 'provided' it doesn't work either. This is an unsolvable issue to me.
I'm using Gradle 4.4 on my Java project with JaCoCo 0.8.0, and Sonar with SonarJava 5.0.1.
I have a class annotated with lombok's #Value and #Builder.
My JaCoCo config in build.gradle looks like this:
jacoco {
toolVersion = "0.8.0"
reportsDir = file("$buildDir/reports/jacoco")
}
jacocoTestReport.doFirst{
classDirectories = files("buildDir/classes")
}
task jacocoReport(type: JacocoReport){
sourceSets sourceSets.main
executionData test, integrationTest
}
Also, I have lombok.confi file, with property lombok.addLombokGeneratedAnnotation = true, and generated stuff does actually have #lombok.Generated annotation in build/classes.
However, the coverage on Sonar is still low. It reports a ton of conditions and lines to cover.
As stated in announcement of release of JaCoCo version 0.8.0:
Please Note
Tools that directly read exec files (which is not a final report) and embed JaCoCo for generation of report will provide filtering functionality only after they updated to this version of JaCoCo.
So please follow/wait/etc respective vendors such as
SonarQube - https://jira.sonarsource.com/browse/SONARJAVA-2608
Reports generated by corresponding version (0.8.0) of integrations developed as part of JaCoCo project by us (Ant Tasks, Maven Plugin and Command Line Interface) provide filtering functionality.
With Gradle JaCoCo Plugin you can select both runtime and version for "JaCoCoReport" task using "toolVersion" - https://docs.gradle.org/current/userguide/jacoco_plugin.html
This is also stated in JaCoCo changelog:
Note: Tools that directly read exec files and embed JaCoCo for this (such as SonarQube or Jenkins) will provide filtering functionality only after they updated to this version of JaCoCo.
As of today (29 Jan 2018) fix for https://jira.sonarsource.com/browse/SONARJAVA-2608 is supposed to be in not yet released SonarJava plugin version 5.1.
From all the above: report generated by Gradle should already be filtered, report generated by SonarQube will be filtered after upgrade of SonarJava.
Apart from configuring lombok, I also had to tell sonar scanner where to find the dependencies. Was the only way to get rid of the "Unused private fields should be removed" message in SonarQube.
I followed instructions from this site: https://netwolfuk.wordpress.com/2017/10/29/maven-sonarqube-jacoco-lombok-and-teamcity/
It boils down to:
Tell maven to copy its dependencies to somewhere Sonar can find them. This is simple as adding:
dependency:copy-dependencies
Add the following to the sonar build step:
-Dsonar.java.libraries=target/dependency/*.jar
New to Sonar. Am comfortable with checkstyle and jacoco.
What I am exploring is in a a gradle project, give developers ability to run style checks and code coverage reports locally, but then use bamboo to publish reports in sonar.
Is this a viable option ? I can see that jacoco plugin and sonar plugin can be in the same build.gradle and so guessing that jacoco reports can be got from sonar. However am unsure how checkstyle integration works. From what I see, I can add a checkstyle plugin to sonar, but then I will have to define rules in SonarQube. I will like to keep checkstyle configuration locally so developers can run a local check before commiting code.
Bear with me if the questions are naive.
Your goal: enable developers to run the same set of rules locally that are applied in a SonarQube scan.
The means: SonarLint offers a "connected mode" for IntelliJ, Eclipse, and Visual Studio. Assuming you're using the SonarQube Analyzers, they'll get on-the-fly checking as they code using the same rule set locally as is applied in an analysis. If the profile changes on the server, it can be manually re-synchronized in the IDE.
The hitch: to make this work seamlessly, you should look at replacing your Checkstyle rules with the ones offered by the SonarQube Analyzer for Java (i.e. the Java plugin). Almost all of the "valuable" rules from Checkstyle have been replaced in the Java plugin.
I've just updated my local Sonar installation to 3.7 from 3.3. Previously, I've analyzed projects with Sonar using the Maven plugin (clean install sonar:sonar). On this old setup, everything works like a charm, more specifically Checkstyle, Findbugs, PMD violations were added to the Sonar analysis.
Since the upgrade, I'm not getting any Checkstyle, Findbugs, PMD results (violations count == 0, which I cannot imagine to be true as a local Eclipse PMD run results in quite some violations to solve).
During upgrade of Sonar 3.7, I had to remove the Checkstyle, PMD, findbugs plugins on Sonar, as they were included in the Java ecosystem (according to the docs).
Am I missing something, or can you give me any pointers to enable analysis?
Cheers,
Jeroen
You must be missing some jars from the Java Ecosystem. The zip file can be found on http://docs.codehaus.org/display/SONAR/Java+Ecosystem
I managed to run findbugs within my maven build process, and I also have findbugs configured in eclipse. However when running in Eclipse and Maven I get different bugs, and I can't seem to find a setting, where the number of bugs matches in Eclipse and Maven.
My Maven settings is like this:
<version>2.5.2</version>
<configuration>
<failOnError>false</failOnError>
<threshold>Normal</threshold>
<effort>Default</effort>
<xmlOutput>true</xmlOutput>
<findbugsXmlOutput>true</findbugsXmlOutput>
<findbugsXmlWithMessages>true</findbugsXmlWithMessages>
</configuration>
And in Eclipse I have:
Findbugs Version: 2.0.1
Analysis Effort: Default
Minimum Rank to report: 20
Minimum Confidence to Report: Medium
Reported categories: All
With those settings, I get more bugs in Eclipse. My main problem is, that I can't even match the different settings between maven and eclipse.
You could try using m2e-code-quality, which includes an m2eclipse 'connector' that should ensure your Eclipse FindBugs configuration matches the configuration specified in your pom.
I'm having exactly the same problem. There is a mismatch between settings available in Eclipse (using FindBugs 2.0.1) and the Maven plugin (version 2.5.2).
One setting that is missing from the Maven plugin is 'confidence'.
Using another piece of software to match the configurations doesn't address the issue because the Eclipse matching just highlights a problem. I want certain bugs reported from the Maven build completely independently of Eclipse that aren't being reported. It just happens that it is possible to have them reported in Eclipse.