kotlin support - reuse of existing functionality of Java plugin?

[Mirko Friedenhagen]

Hello everybody,

I just started some playstuff with Kotlin and like it. I am working in build engineering and we use SonarQube a lot.

What would be the recommended way to implement a new plugin for a JVM language which mostly uses Maven or relies on structures similar to Maven, e.g. test results are found at target/surefire-reports etc.

I just installed SQ 6.2 locally and tried some different approaches:

## Reconfigure SQ to handle kotlin like java.

* I started the analysis with `mvn verify sonar:sonar -Dsonar.java.file.suffixes=.kt -Dsonar.login=admin -Dsonar.password=admin`, the project already uses jacoco-0.7.8

* This led to an expectable parse error with the "Java Main Files AST scan".

* Lateron the Surefire and Jacoco  sensors could not find any files, which is understandable.

Then I forked I forked the kotlin-sonar[0] plugin which provides only very basic XML-rule support and tried different approaches

to get coverage (and surefire) running, see my fork at [1]:

## Brute-Force copy of the groovy-plugin

* In the master branch I just copied and adapted the code from the groovy-plugin as a POC, coverage was shown and unit tests results were reported.

* One issue I ran into during coverage reporting was a inconsistency concerning line numbers which led to a IllegalStateException in NewCoverage which I catched in the this approach[5]:

** With Kotlin you often get multiple class files (see e.g AKotlinThing.kt[3], where the compiler produces three class files[4])

** The code coverage seems to only take into account the information for the "main" class and seems to be confused later on because the source file reports more lines than the coverage coming via jacoco.exec

## Facading the java-plugin)

* Now this did work somehow, however it seems to be a *huge* invest as a lot of method calls are already deprecated as of today and this is quite untested.

* Because SQ is quite quick in making incompatible API changes, I thought of reusing the officially supported java-plugin which seems to be a lesser effort.

* As outlined in the previous approach, the Jacoco Sensors fail, because the last-line information found in jacoco.exec does not correspond to the lines of the source file. 

* SonarQube bails with something like:

  at org.sonar.api.internal.google.common.base.Preconditions.checkState(Preconditions.java:173)
  at org.sonar.api.batch.sensor.coverage.internal.DefaultCoverage.validateLine(DefaultCoverage.java:89)
  at org.sonar.api.batch.sensor.coverage.internal.DefaultCoverage.lineHits(DefaultCoverage.java:77)
  at org.sonar.plugins.jacoco.AbstractAnalyzer.analyzeFile(AbstractAnalyzer.java:256)
  at org.sonar.plugins.jacoco.AbstractAnalyzer.readExecutionData(AbstractAnalyzer.java:139)
  at org.sonar.plugins.jacoco.AbstractAnalyzer.analyse(AbstractAnalyzer.java:102)
  at org.sonar.plugins.jacoco.JaCoCoSensor.execute(JaCoCoSensor.java:87)

If you read up until, thanks a lot :-).

Now to reiterate: what would be the recommended way to implement a new plugin for a JVM language which mostly uses Maven?

Thanks for any comments

Mirko

[0] https://github.com/K0zka/kotlin-sonar

[1] https://gitlab.com/mfriedenhagen/kotlin-sonar

[3] https://gitlab.com/mfriedenhagen/kotlin-sonar/blob/4774b78a8815c1c03c874c409ad8f64eafb3a4a6/src/test/resources/test_data/com/example/AKotlinThing.kt

[4] https://gitlab.com/mfriedenhagen/kotlin-sonar/tree/4774b78a8815c1c03c874c409ad8f64eafb3a4a6/src/test/resources/test_data/com/example

[5] https://gitlab.com/mfriedenhagen/kotlin-sonar/blob/e9a94afddda6b5d454d7d9daaa604eacc0147e4a/src/main/kotlin/io/github/K0zka/kotlinsonar/jacoco/AbstractAnalyzer.kt#L128

[Nicolas Peru]

Hi, 

Sorry for the delay before answering.

There are no clear and straightforward answer to your question as it will mainly depend on your ambitions.

First approach is clearly not gonna work... parse error are only the tip of the iceberg. 

We used to have dependency mechanism between plugins and this is a nightmare in terms of version and backward compatibilty so we tend to not enfore this (the only still existing exception might be FindBugs plugin which is (maybe?) still relying on some SonarJava parts).  So this excludes facading java plugin. 

If the goal is only to compute a bunch of metrics, and maybe implement a few rules, then I think taking inspiration from the groovy plugin might be enough.

Adapting the jacoco sensors from the java plugin and using a kotlin parser to get AST and compute some metrics and or implement some rule should do the trick. 

HTH, 

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/8334bc0f-0f12-4b07-9a19-debb65e23294%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico