That is exactly the point. There are different opinions about stuff like that. And there are companies out there choosing not to use IntelliJ. There are people using eclipse or probably some people just using a basic text editor. I think this plugin would be good just so there are options to choose from. It’s not like static analysis is a solved problem
I agree that diversity is generally a good thing. But I have the suspicion that many users are longing for SonarQube (for Java or Kotlin), because they aren’t aware of the possibility to use IntelliJ inspections on a CI server.
By the way: Using Kotlin with Eclipse is hardly advisable at the current state of the Kotlin Plugin.
I can not say how the Kotlin plugin is for eclipse as I am a happy user of intellij. Still I think that in the long term more options are better than fewer.
Could well be true. As I don’t use Kotlin/Intellij in a professional setting I don’t know how much tools like this are used in Kotlin already.
My team is aware of that, but we are happy the way our pipeline is set up with SonarQube right now, and we don’t want to have to change that.
I’m using Detekt for static analysis. GitHub - detekt/detekt: Static code analysis for Kotlin and highly recommend it. Ties in very nicely to Gradle.
The author has provided a preliminary Sonarqube plugin. GitHub - detekt/sonar-kotlin: SonarQube plugin for Kotlin.
I am using it at my corporate employer to satisfy the requirement that all projects must show Issues and coverage in Sonarqube.
Fortunately the ‘owners’ of Sonarqube were willing to install a plugin built from source as this plugin has not been published to the Sonarqube Update Centre.
This will hopefully help some of you get past this roadblock to Kotlin adoption.
Greetings were you able to upload the coverage tests? Our team is having troubles with that.
Using Jacoco gradle plugin (0.8.0)
Using Sonar gradle plugin (2.6.2)
Yes I was. The ‘magic’ configuration was this. Let’s sonarqube/jacoco find the kotlin files. Note that my project is 100% Kotlin, hence the explicit setting to kotlin classes, and it’s Gradle 4+.
If you have a mixed project, you’ll likely need to add to the sonar.java.binaries property.
I spent a bit of time experimenting with this. Using Docker and the Sonarqube container at DockerHub was a HUGE benefit. Sped up attempts significantly.
sonarqube {
properties {
property 'sonar.java.binaries', "$projectDir/build/classes/kotlin"
}
}
As far as I understand, Sonar JIRA is open for everyone for read.
So we can track a progress of official Kotlin plugin development starting from here
1 Like
Hi everyone,
I guess I should start with a disclaimer: I’m an engineer @ SonarSource, the company that maintains SonarQube. Having seen this thread, and notably that last note below, If feel compelled to give you a heads-up on the SonarQube+Kotlin situation, and essentially share some good news.
Indeed this Jira entry is the overarching tracking item for the various new languages that we want our products to support in 2018. Kotlin is one that we worked on a couple of months back, and so in the context of this thread you should now that Kotlin is natively supported since SonarQube 7.3 . (since then, SonarQube 7.4 also landed with native Ruby support, but that’s another topic). All open-source goodness by the way 
It’s only fair to remind that all the same is available via SonarCloud (in case your Kotlin code is in GitHub/BitBucket/AzureDevops).
Last but not least, the same Kotlin rules that SonarQube now has built-in, are also available for on-the-fly inspection in IntelliJ. We provide them via SonarLint, which just received Kotlin support.
Again I took the liberty to give a focused product update here because the thread is clearly marked as SonarQube-oriented. I’m happy to share other insights if needed (and if any feedback, we’re also listening on our community forum.
4 Likes
How can I integrate SonarQube with my Kotlin project with gradle?