Issues showing in SonarLint for Eclipse that don't show in connected SonarQube project

(KC Baltz) #1

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?

(Julien Henry) #2

Hi @KC_Baltz

For the first problem, it could be caused by multiple factors:

  • file is analyzed by SonarLint, but not by SonarQube. Depends how you configure scanner properties, inclusions/exclusions, …
  • file is classified as main source code by SonarLint, but as test by SonarQube (most rules are not executed on tests)
    Having SonarLint console output (in verbose mode) when opening the file would give some details.

For the second problem, this is easy. SonarLint only executes SonarSource code analyzers, not third party plugins.

(KC Baltz) #3

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 ms
(Julien Henry) #4

We’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.

(KC Baltz) #5

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.

(Julien Henry) #6

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.