@mwz I’m was still fascinated as to why in https://github.com/mwz/sonar-scala/blob/master/examples/mvn/multi-module/pom.xml scapegoat is not running against the tests but only the sources, and it really looks like it has the same problem I see
Scapegoat does run against the test source and does override the source reports when I run the example on local, unless I feed it different
-P:scapegoat:dataDir for the compile and testCompile goals
If I run
mvn clean install on local on the sample project with no changes, the resulting scapegoat.xml files in the module target directories contain no issues.
It made no sense for maven to be any different from gradle in this regard, looking at sksamuel/scapegoat#254
the fix is to do something like
<executions>
<execution>
<id>source-compile</id>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<args>
<arg>-P:scapegoat:dataDir:${project.build.directory}</arg>
</args>
</configuration>
</execution>
<execution>
<id>test-compile</id>
<goals>
<goal>testCompile</goal>
</goals>
<configuration>
<args>
<arg>-P:scapegoat:dataDir:${project.build.directory}/tests</arg>
</args>
</configuration>
</execution>
</executions>
Or rather, recompile the sources after running the tests
yeah in fact that’s how the example project is set up to run - https://github.com/mwz/sonar-scala/blob/master/examples/scan.sh#L42
It’s not a proper solution but a workaround that I settled on. I don’t use mvn so I didn’t want to invest much time into fixing this properly, but if you have a fix them I’d be happy to accept a PR.
It’s not a proper solution but a workaround that I settled on. I don’t use mvn so I didn’t want to invest much time into fixing this properly, but if you have a fix them I’d be happy to accept a PR.
I’m actually considering doing the same workaround rather than keeping the complexity in the pom. It’s particularly painful when you’re using extra scalac plugins as you need to maintain both a common configuration with the common set of arguments as well as particular configs for each execution with
combine.children / combine.self properties to make sure maven merges everything as expected. Perhaps it’s better just to add an extra observation to the readme that explains why it’s mandatory to specify the scala:compile goal after the test goal. What do you think?
Also, any idea if, and if not - why, this problem does not manifest for
sbt?
Hi, is there any special local configuration required for sbt-sonar (2.1.1) to work with SonarQube 6.7?
When i run
Or does that mean that the server has an incompatible (plugin) version (referring to the sonar-scala compatibility matrix in the docs)?
When i run
sonarScan against the docker container listed in the documentation everything works but i loose (at least) all coverage data when running against our 6.7 SonarQube.Or does that mean that the server has an incompatible (plugin) version (referring to the sonar-scala compatibility matrix in the docs)?
If you’re installing sonar-scala manually then check v6.8.0 against your SonarQube instance, that’s the version that’s bundled in the
sonarqube-scala-plugins:2.12.0-full image.
Also I’d recommend migrating to the latest SonarQube LTS if you can as 6.7 is no longer supported.
Thanks for the response!
Unfortunately, i can't do anything about the SubarQube version ...
However, i could fix the problem by adding the following
In my case this causes a FileNotException during
I can't say why this works but maybe it'll help someone else ...
Unfortunately, i can't do anything about the SubarQube version ...
However, i could fix the problem by adding the following
sonarProperties entry to the root module of the multi module build:"sonar.scala.coverage.reportPaths" -> sonarProperties.value("sonar.scala.scoverage.reportPath") (note that it is coverage.reportPath*s* instead of *s**coverage.reportPath)In my case this causes a FileNotException during
sonarScan because the root module has no sources and thus no coverage reports. But the coverage reporting now works.I can't say why this works but maybe it'll help someone else ...
Then it would appear that you’re using the SonarScala plugin rather than sonar-scala.
There is an incomplete PR in sbt-sonar (mwz/sbt-sonar#45) which attempts to make sbt-sonar compatible with SonarScala so that you don’t need to fiddle with those path properties. It hasn’t been finished off by the author, so if you’re keen to contribute it’s an easy one to pick up.
There is an incomplete PR in sbt-sonar (mwz/sbt-sonar#45) which attempts to make sbt-sonar compatible with SonarScala so that you don’t need to fiddle with those path properties. It hasn’t been finished off by the author, so if you’re keen to contribute it’s an easy one to pick up.
@/all sbt-sonar 2.2.0 was released with the ability to toggle compatibility between sonar-scala and SonarScala plugins.
Hi All, I setup Sonarqube 8.4 and tried to install the sonar-scala plugin 8.4 version and it started to fail :(
java.lang.IllegalStateException: Unable to read plugin manifest from jar : is there a way I can make sonar-scala 8.4 version work with the latest Sonarqube.
1 reply
@adityamenongithub it seems the plugin hasn't been updated for
Also, you can build that plugin locally and use it until the official release is done.
8.4 yet, you may open a PR upgrading the dependency and fixing any build / test errors you find; I am sure Micahel will be grateful for that and release a new version ASAP.Also, you can build that plugin locally and use it until the official release is done.
Hi @mwz since my SBT skill are the worst my friend @franbh helped me with the pull request for the new SonarQube compatibility with
8.4 mwz/sonar-scala-docker#28 I took the new jar file from https://dl.bintray.com/mwz/maven/com/github/mwz/sonar-scala_2.13/8.5.0/sonar-scala_2.13-8.5.0-assembly.jar and added it to the plugins directory with the same error java.lang.IllegalStateException: Unable to read plugin manifest from jar : /opt/sonarqube/extensions/plugins/sonar-scala_2.13-8.5.0-assembly.jar
at org.sonar.updatecenter.common.PluginManifest.<init>(PluginManifest.java:125)
at org.sonar.core.platform.PluginInfo.create(PluginInfo.java:412)
at org.sonar.server.plugins.ServerPluginRepository.loadPreInstalledPlugins(ServerPluginRepository.java:135)
1 reply
@mwz forgot to let you know about this, I couldn't get the jar working so I used the docker image https://hub.docker.com/r/mwizner/sonarqube-scala-plugins and looks like its working for me and seems like a better way than the jar. Thanks for your help
Hi @exoego, yes sbt-sonar can be used with SonarCloud. Setting
sonarExpectSonarQubeCommunityPlugin to false allows you to switch compatibility from sonar-scala to SonarScala, which is the default Scala plugin available on SonarCloud. See the release notes for 2.2.0.
Hey there, I'm a developer at SonarSource, leading the development of the SonarJava analyzer.
Would it be possible to share a few words with the main maintainers of sonar-scala? :)
I've been trying to find an email address but didn't find anything adequate (and wanted to avoid linkedin in-messages)
@mwz maybe?
Would it be possible to share a few words with the main maintainers of sonar-scala? :)
I've been trying to find an email address but didn't find anything adequate (and wanted to avoid linkedin in-messages)
@mwz maybe?
I'll stay around for a while, but feel free to contact me by email (michael.gumowski@sonarsource.com). We could also discuss directly through zoom or google hangout.
Cheers :)
Cheers :)
Hi. I want to use sonar-scala with scapegoat and maven. But scapegoat always fails the compile. I would love to just get a report, like with scoverage and scalastyle instead of a failing compile. Is this possible? On the web I only found the answer to use overrideLevels but that would mean I need to do this for each error, right?
Yeah, I generally prefer to override the level of specific inspections if I have to, although it's obviously recommended to not have any errors in a first place :smile:
Keep in mind that if you use sonar-scala, then the level of those inspections reported to SonarQube is determined by the levels set in your quality profile, so the local overrides don't really have any impact on your issues reported back other than just preventing Scapegoat from failing.
Keep in mind that if you use sonar-scala, then the level of those inspections reported to SonarQube is determined by the levels set in your quality profile, so the local overrides don't really have any impact on your issues reported back other than just preventing Scapegoat from failing.