I’m using SonarLint for Eclipse version 4.1.0.xxx and SonarQube server (Community Edition Version 7.3 (build 15553)) .
I’ve got a project that’s bound to the SQ server and SonarLint is reporting issues (e.g. Members of Spring components should be injected (squid:S3749)) that I don’t see on the SQ server and SQ has issues I don’t see in SonarLint (e.g. findsecbugs:SQL_INJECTION_JPA). The project appears to be bound correctly.
Suggestions?
Hi @KC_Baltz
For the first problem, it could be caused by multiple factors:
For the second problem, this is easy. SonarLint only executes SonarSource code analyzers, not third party plugins.
OK, I can understand SL not running third-party tests and can live with that, although it would be nice if SL at least showed the results from the SQ server to help me address them in the Eclipse UI.
As to your other questions, all the issues I mentioned are with the same .java file, so both SL and SQ are scanning it. I’m not sure why SQ would classify it as test or how to confirm if that’s what’s happening. We’re running the SQ scanner in Jenkins and it appears to be version 3.2.0.1227.
I just tried enabling the verbose SL console logs and I don’t see anything concerning. I’ll paste the results after editing the file and saving it to trigger and SL scan:
Trigger: EDITOR_CHANGE
Clear markers on 0 excluded files
SonarLint processing file /zendesk-automation/src/main/java/com/copart/automation/zendesk/dao/ZDJpaDao.java...
Connected mode (using configuration of 'zendesk-automation' in server 'sonarqube.copart.com')
Starting analysis with configuration:
[
projectKey: zendesk-automation
baseDir: /Users/kcbaltz/git/zendesk-automation
workDir: /Users/kcbaltz/Documents/workspace/.metadata/.plugins/org.eclipse.core.resources/.projects/zendesk-automation/org.sonarlint.eclipse.core
extraProperties: {sonar.java.target=1.8, sonar.java.libraries=...
inputFiles: [
file:/Users/kcbaltz/git/zendesk-automation/src/main/java/com/copart/automation/zendesk/dao/ZDJpaDao.java (UTF-8)
]
]
Found 2 issue(s)
Done in 104 msWe’re running the SQ scanner in Jenkins and it appears to be version 3.2.0.1227.
Isn’t your project a Maven project? Why aren’t you using the Scanner for Maven? How are you providing the classpath properties (sonar.java.libraries / sonar.java.binaries)?
FYI most SonarJava rules requires to have a proper classpath configured, to resolve types and method behaviors.
We’re new to SQ and learning the best way to run it. Our DevOps guys installed the plugin so I thought that was the way to run it. However, you’re correct that running the scanner from Maven fixed the problem. I ran out of time to try that from our Jenkins server, but running it locally, connected to our SQ server produced the matching results I was looking for.
As for how we’re providing all those properties, the Jenkins plugin has a config box to put them in. I used the same properties to configure my Maven. At this point, I’m thinking the issue is one of versioning, but either way, since your’e saying running it directly as a Maven goal is preferable, we’ll push towards that way.
As for how we’re providing all those properties, the Jenkins plugin has a config box to put them in.
Maintaining manually the properties sonar.java.binaries/libraries is a pain. You would have to remember updating it each time you add/update a dependency in your pom.xml. That’s why for Maven projects we recommend using our Maven plugin to trigger analysis, instead of using the standalone CLI scanner.
Hello @Julien_HENRY
Will third party plugins be taken into account in any future release of SonarLint?
Installing third party plugins is very usual in SonarQube, so it would the nice if developers could obtain the same analysis results in SonarLint as in the SonarQube server.
Regards.
JM
Hi @jmcubel
That’s not in our plans. Most of the time, third party analyzers have their own IDE integration, so we advice people to use them. SonarLint is dedicated to IDE integration of SonarSource analyzers.
I see, thanks for the reply 