pmayweg / sonar-groovy Goto Github PK

Hey there.

I'm using sonar-groovy version 1.5 with Java 10 (and gradle) and am getting the following error:

Exception during analysis of file C:\project\build\classes\groovy\main\project\example\Users.class
java.io.IOException: Error while analyzing class C:\project\build\classes\groovy\main\project\example\Users.class.
        at org.jacoco.core.analysis.Analyzer.analyzerError(Analyzer.java:150)
        at org.jacoco.core.analysis.Analyzer.analyzeClass(Analyzer.java:144)
        at org.sonar.plugins.groovy.jacoco.JaCoCoReportReader.analyzeClassFile(JaCoCoReportReader.java:137)
        at org.sonar.plugins.groovy.jacoco.JaCoCoReportReader.analyzeFiles(JaCoCoReportReader.java:112)
        at org.sonar.plugins.groovy.jacoco.AbstractAnalyzer.readExecutionData(AbstractAnalyzer.java:153)
        at org.sonar.plugins.groovy.jacoco.AbstractAnalyzer.analyse(AbstractAnalyzer.java:108)
        at org.sonar.plugins.groovy.jacoco.JaCoCoOverallSensor.execute(JaCoCoOverallSensor.java:63)
        at org.sonar.scanner.sensor.SensorWrapper.analyse(SensorWrapper.java:53)
        at org.sonar.scanner.phases.SensorsExecutor.executeSensor(SensorsExecutor.java:88)
        at org.sonar.scanner.phases.SensorsExecutor.execute(SensorsExecutor.java:82)
        at org.sonar.scanner.phases.SensorsExecutor.execute(SensorsExecutor.java:68)
        at org.sonar.scanner.phases.AbstractPhaseExecutor.execute(AbstractPhaseExecutor.java:88)
        at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:180)
        at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
        at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
        at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:302)
        at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:297)
        at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:271)
        at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
        at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
        at org.sonar.scanner.task.ScanTask.execute(ScanTask.java:48)
        at org.sonar.scanner.task.TaskContainer.doAfterStart(TaskContainer.java:84)
        at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
        at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
        at org.sonar.scanner.bootstrap.GlobalContainer.executeTask(GlobalContainer.java:121)
        at org.sonar.batch.bootstrapper.Batch.doExecuteTask(Batch.java:116)
        at org.sonar.batch.bootstrapper.Batch.executeTask(Batch.java:111)
        at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:63)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
        at com.sun.proxy.$Proxy116.execute(Unknown Source)
        at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:233)
        at org.sonarsource.scanner.api.EmbeddedScanner.runAnalysis(EmbeddedScanner.java:151)
        at org.sonarqube.gradle.SonarQubeTask.run(SonarQubeTask.java:99)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:46)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:39)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:26)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:794)
        at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:761)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:124)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:317)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:309)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:185)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:97)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:113)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:95)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:73)
        at org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51)
        at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:59)
        at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54)
        at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:59)
        at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:101)
        at org.gradle.api.internal.tasks.execution.FinalizeInputFilePropertiesTaskExecuter.execute(FinalizeInputFilePropertiesTaskExecuter.java:44)
        at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:91)
        at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:62)
        at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:59)
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
        at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
        at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:256)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:317)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:309)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:185)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:97)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:249)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:238)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:104)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:98)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:663)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:596)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:98)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
        at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.IllegalArgumentException: null
        at org.objectweb.asm.ClassReader.<init>(ClassReader.java:170)
        at org.objectweb.asm.ClassReader.<init>(ClassReader.java:153)
        at org.objectweb.asm.ClassReader.<init>(ClassReader.java:424)
        at org.jacoco.core.analysis.Analyzer.analyzeClass(Analyzer.java:142)
        ... 85 common frames omitted

I believe this is due to the fact the only the latest version of Jacoco supports Java 10: https://github.com/jacoco/jacoco/releases/tag/v0.8.1

And the version the plugin currently uses is 0.7.5.201505241946.

Any chance we can upgrade?

I could provide the PR, if that's the only needed step.

Thanks!

I'm using SQ 7.7 and installed plugin sonar-groovy-plugin-1.5. During my tests I got error:
14:39:01.152 ERROR: Error during SonarQube Scanner execution org.picocontainer.injectors.AbstractInjector$UnsatisfiableDependenciesException: org.sonar.plugins.groovy.codenarc.CodeNarcSensor has unsatisfied dependency 'class org.sonar.plugins.groovy.foundation.GroovyFileSystem' for constructor 'public org.sonar.plugins.groovy.codenarc.CodeNarcSensor(org.sonar.api.profiles.RulesProfile,org.sonar.plugins.groovy.foundation.GroovyFileSystem)' from org.sonar.core.platform.ComponentContainer$ExtendedDefaultPicoContainer@6a1ebcff:111<[Immutable]:org.sonar.core.platform.ComponentContainer$ExtendedDefaultPicoContainer@f58853c:307<[Immutable]:org.sonar.core.platform.ComponentContainer$ExtendedDefaultPicoContainer@67b61834:59<|

Hello

I have a Grails project configured with (build.gradle):

tasks.withType(CodeNarc) {
    it.reports {
        xml.enabled = true
        html.enabled = true
    }
    it.ignoreFailures = true
    it.configFile = file('config/codenarc/codenarc.groovy')
}

This generates 3 XML files (~\myproject\build\reports\codenarc): main.xml, test.xml and integrationTest.xml

According to: sonar-groovy

"It is possible to reuse a previously generated report from CodeNarc by setting the sonar.groovy.codenarc.reportPath property."

I cannot seem to set sonar.groovy.codenarc.reportPath to multiple XML files. Any ideas?

Thanks

Mark

These APIs will be dropped in SQ 7.3, for example:

• sonar-scanner-cli-4.2.0.1873-windows

• error observed: java.lang.IllegalArgumentException: 64 is not a valid line offset for pointer. File test.groovy has 63 character(s) at line 3

• potential workaround: No workaround yet

Whole code is:

try {
setAttribute(‘RequestedTimeSlot’, ‘NA’);
if(WoArea == “AC Power – Canada” || WoArea == “AC Power - US”)
{
if (WoTypeId == 300000890102345) {
setAttribute(‘AreaType_c’, “AC_POWER_MAINTENANCE”)
} else if (WoTypeId == 300000890102347) {
setAttribute(‘AreaType_c’, “AC_POWER_INSTALL”)
} else if (WoTypeId == 300000890102341) {
setAttribute(‘AreaType_c’, “AC_POWER_EMERGENCY”)
} else if (WoTypeId == 300000890102343) {
setAttribute(‘AreaType_c’, “AC_POWER_PM”)
} else if (WoTypeId == 300000890102346) {
setAttribute(‘AreaType_c’, “AC_POWER_START_UP”)
} else if (WoTypeId == 300000890102342) {
setAttribute(‘AreaType_c’, “AC_POWER_TRAINING”)
} else {
setAttribute(‘AreaType_c’, null)
}
}
else if (WoArea == ‘DC Power - US’ || WoArea == ‘DC Power – Canada’) {
if (WoTypeId == 300000890102345) {
setAttribute(‘AreaType_c’, “DC_POWER_MAINTENANCE”)
} else if (WoTypeId == 300000890102347) {
setAttribute(‘AreaType_c’, “DC_POWER_INSTALL”)
} else if (WoTypeId == 300000890102341) {
setAttribute(‘AreaType_c’, “DC_POWER_EMERGENCY”)
} else if (WoTypeId == 300000890102343) {
setAttribute(‘AreaType_c’, “DC_POWER_PM”)
} else if (WoTypeId == 300000890102346) {
setAttribute(‘AreaType_c’, “DC_POWER_START_UP”)
} else {
setAttribute(‘AreaType_c’, null)
}
}
else {
setAttribute(‘AreaType_c’, null)
}
} catch (e) {
adf.error.raise(null)
}

Hi, i'm new to sonar, and still testing things.
I noticed that with the groovy plugin installed the sonar.projectBaseDir seems to be ignored.
The sonar then scans the whole computer (localy i get info log about to much links in .steam/... folder.

I use the latest plugin version (sonar-grovy-plugin-1.8.jar) downloaded from git and copy past in extensions/plugin/ folder
And the sonar scan gets lauched from gradle task

./gradlew -v
------------------------------------------------------------
Gradle 6.5
------------------------------------------------------------

Build time:   2020-06-02 20:46:21 UTC
Revision:     a27f41e4ae5e8a41ab9b19f8dd6d86d7b384dad4

Kotlin:       1.3.72
Groovy:       2.5.11
Ant:          Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM:          11.0.17 (Oracle Corporation 11.0.17+1)
OS:           Linux 5.15.81-1-MANJARO amd64

// build.gradle
plugins {
    id 'application'
    id 'groovy'
    id 'eclipse'
    id 'checkstyle'
    id 'maven-publish'
    id 'at.bxm.svntools' version '2.2.1' // Don't update as long as we don't use Java 11, it's needed by version 3
    id 'org.asciidoctor.convert' version '2.4.0' // About org.asciidoctor.jvm.convert as it says itself: "If you need a production-ready version of the AsciidoctorJ plugin for Gradle use a 1.5.x release of 'org.asciidoctor.convert' instead"
    id 'org.owasp.dependencycheck' version '6.3.1' apply false
    id 'se.patrikerdes.use-latest-versions' version '0.2.17' apply false
    id 'com.github.ben-manes.versions' version '0.39.0' apply false
    id "com.github.ManifestClasspath" version "0.1.0-RELEASE"
    id "com.github.node-gradle.node" version "3.1.0"
    id "org.sonarqube" version "3.5.0.2730"
}

Would you have an explanatoin or workaround ?
If there is any more info needed please let me know

Hi All,

We were trying to download sonar groovy plugin 1.5 jar file but it is not allowing us to download so we downloaded the source code and tried to build the job but it was failing due to test case failure with below errors:
" at org.sonar.plugins.groovy.codenarc.CodeNarcSensorTest.should_parse(Cod
NarcSensorTest.java:112)

unning org.sonar.plugins.groovy.jacoco.ExecutionDataVisitorTest
ests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in org.s
nar.plugins.groovy.jacoco.ExecutionDataVisitorTest
unning org.sonar.plugins.groovy.jacoco.JaCoCoConfigurationTest
ests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec - in o
g.sonar.plugins.groovy.jacoco.JaCoCoConfigurationTest
unning org.sonar.plugins.groovy.GroovySensorTest
RROR Unable to read file: unknownFile.groovy
ava.io.FileNotFoundException: J:\sonarplugins\sonar-groovy-1.5\sonar-groovy-1.5
sonar-groovy-plugin\unknownFile.groovy (The system cannot find the file specifi
d)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.(FileInputStream.java:138)
at org.sonar.plugins.groovy.foundation.GroovyHighlighterAndTokenizer.pro
essFile(GroovyHighlighterAndTokenizer.java:164)
at org.sonar.plugins.groovy.GroovySensor.highlightFiles(GroovySensor.java"

can you please provide us the correct jar file or correct source code with all dependency provided so that we can create jar file for the same.

Regards

We use the plugin mainly for our tests which are written in the awesome spock framework.

However, we noticed that at least three rules are applied to the test method name that don't make any sense in the context of a test method:

• grvy:org.codenarc.rule.convention.NoDefRule
• grvy:org.codenarc.rule.naming.MethodNameRule.fixed
• grvy:org.codenarc.rule.junit.JUnitPublicNonTestMethodRule

Here is some sample code that produces those issues

@SpringBootTest
class EndpointHealthCheckIntegrationTest extends Specification {
  @Autowired
  private EndpointHealthCheck healthCheck

  def "endpoint is up and running"() {
    when: 'health is queried'
    Health health = healthCheck.health().block()
    then: 'status should be up'
    health.status == Status.UP
  }
}

I resolve those issues as false positives and have to do it for every test method which is kinda annoying.

• the convention for spock test methods is to use def and write a meaningful name (as GString) instead of a JUnit-style identifier
• the JUnit rule is applied to this kind of tests (I guess because Spock uses JUnit in the background). It clearly can't identify the method as a test and tells me that all methods but tests should not be public.

Hi all,

Any way to enable groovy interpretation within cdata?
the software I'm using generates xml files and contains groovy code inside

<script><![CDATA[import com.lib1.esb.;&#13; &#13; def demo1= INPUTS["var1"]&#13; .. ]]></script>

Hello

I'm using Sonarqube with the stash plugin:

https://github.com/AmadeusITGroup/sonar-stash

I'm trying to use the gradle sonarqube plugin and have added the following parameters:

gradlew sonarqube -Dsonar.stash.notification -Dsonar.stash.project=#{stash.project} -Dsonar.stash.repository=#{stash.repository} -Dsonar.stash.pullrequest.id=$GO_SCM_#{material.name}_PR_ID -Dsonar.stash.login=$GIT_USER -Dsonar.stash.password=$GIT_PASSWORD

However, the Sonar report is not appearing in my pull request.

Are these parameters recognized in the sonarqube plugin?

Thanks

Mark

Hi!
Some issues like :
grvy:org.codenarc.rule.imports.UnusedImportRule
grvy:org.codenarc.rule.unused.UnusedPrivateFieldR
should be set to Code Smell instead of Bug.

In general the Groovy rules should follow the Java rule categories.

Thanks and cheers,
Balázs

Please provide a link to manual download the plugin.
wget https://some url to plugin in Jar
This will help facilitate the creation of a docker image that has this plugin jar as part of the image.

In a maven multi module project I can set <sonar.java.binaries> as:

<sonar.java.binaries>${project.build.directory}/classes/**</sonar.java.binaries>

and it picks up everything within the child modules. The same doesn't happen with with sonar.groovy.binaries where I need to do this:

<sonar.groovy.binaries>
${project.basedir}/my-child-module/target/classes/com/my-company/my-team/my-app/my-api/dao,
${project.basedir}/my-child-module/target/classes/com/my-company/my-team/my-app/my-api/service,
${project.basedir}/my-child-module/target/classes/com/my-company/my-team/my-app/my-api/workflow,
${project.basedir}/my-child-module/target/classes/com/my-company/my-team/my-app/my-api/config
</sonar.groovy.binaries>

There's actually two issues here together -- the other being that the code assumes all .class files will be inside the /target/classes directory, and does not recursively search inside all the folders present. I need to then list out every possible package name in my project to get all of them. In the above example I had to list .dao .service. workflow .config subpackages individually to get it to work.

CodeNarc 1.1 is out. It would be great if sonar-groovy can use this version.

Hi

I am getting below error when sonarqube tries to analyse the groovy files.

2019-01-29T09:59:16.9751645Z 10:59:16.974 DEBUG: 'Sprint Release.groovy' generated metadata with charset 'UTF-8'
2019-01-29T09:59:17.0140545Z 10:59:17.008 DEBUG: 'Release-NL.groovy' generated metadata with charset 'UTF-8'
2019-01-29T09:59:17.0261678Z 10:59:17.025 DEBUG: 'MonthlyGenericTasks.groovy' generated metadata with charset 'UTF-8'
2019-01-29T09:59:17.0375961Z 10:59:17.036 DEBUG: 'Release-BE.groovy' generated metadata with charset 'windows-1252'
2019-01-29T09:59:17.0482270Z 10:59:17.047 INFO: Sensor CodeNarc [groovy] (done) | time=8355ms
2019-01-29T09:59:17.0482912Z 10:59:17.047 INFO: Sensor GroovySensor [groovy]
2019-01-29T09:59:17.0558088Z ##[error]10:59:17.054 ERROR: Unexpected token when lexing file : MonthlyGenericTasks.groovy
groovyjarjarantlr.TokenStreamRecognitionException: unexpected char: 0xBB
at org.codehaus.groovy.antlr.parser.GroovyLexer.nextToken(GroovyLexer.java:728)
at org.codehaus.groovy.antlr.parser.GroovyLexer$1.nextToken(GroovyLexer.java:262)
at org.sonar.plugins.groovy.GroovySensor.computeBaseMetrics(GroovySensor.java:221)
at org.sonar.plugins.groovy.GroovySensor.computeBaseMetrics(GroovySensor.java:203)
at org.sonar.plugins.groovy.GroovySensor.execute(GroovySensor.java:107)
at org.sonar.scanner.sensor.SensorWrapper.analyse(SensorWrapper.java:53)
at org.sonar.scanner.phases.SensorsExecutor.executeSensor(SensorsExecutor.java:88)
at org.sonar.scanner.phases.SensorsExecutor.execute(SensorsExecutor.java:82)
at org.sonar.scanner.phases.SensorsExecutor.execute(SensorsExecutor.java:68)
at org.sonar.scanner.phases.AbstractPhaseExecutor.execute(AbstractPhaseExecutor.java:88)
at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:180)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:288)
at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:283)
at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:261)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
at org.sonar.scanner.task.ScanTask.execute(ScanTask.java:48)
at org.sonar.scanner.task.TaskContainer.doAfterStart(TaskContainer.java:84)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
at org.sonar.scanner.bootstrap.GlobalContainer.executeTask(GlobalContainer.java:121)
at org.sonar.batch.bootstrapper.Batch.doExecuteTask(Batch.java:116)
at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:71)
at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
at com.sun.proxy.$Proxy0.execute(Unknown Source)
at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:171)
at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:128)
at org.sonarsource.scanner.cli.Main.execute(Main.java:111)
at org.sonarsource.scanner.cli.Main.execute(Main.java:75)
at org.sonarsource.scanner.cli.Main.main(Main.java:61)
2019-01-29T09:59:17.0560129Z ##[debug]Processed: ##vso[task.logissue type=error;]10:59:17.054 ERROR: Unexpected token when lexing file : MonthlyGenericTasks.groovy%0Agroovyjarjarantlr.TokenStreamRecognitionException: unexpected char: 0xBB%0D%0A at org.codehaus.groovy.antlr.parser.GroovyLexer.nextToken(GroovyLexer.java:728)%0D%0A at org.codehaus.groovy.antlr.parser.GroovyLexer$1.nextToken(GroovyLexer.java:262)%0D%0A at org.sonar.plugins.groovy.GroovySensor.computeBaseMetrics(GroovySensor.java:221)%0D%0A at org.sonar.plugins.groovy.GroovySensor.computeBaseMetrics(GroovySensor.java:203)%0D%0A at org.sonar.plugins.groovy.GroovySensor.execute(GroovySensor.java:107)%0D%0A at org.sonar.scanner.sensor.SensorWrapper.analyse(SensorWrapper.java:53)%0D%0A at org.sonar.scanner.phases.SensorsExecutor.executeSensor(SensorsExecutor.java:88)%0D%0A at org.sonar.scanner.phases.SensorsExecutor.execute(SensorsExecutor.java:82)%0D%0A at org.sonar.scanner.phases.SensorsExecutor.execute(SensorsExecutor.java:68)%0D%0A at org.sonar.scanner.phases.AbstractPhaseExecutor.execute(AbstractPhaseExecutor.java:88)%0D%0A at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:180)%0D%0A at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)%0D%0A at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)%0D%0A at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:288)%0D%0A at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:283)%0D%0A at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:261)%0D%0A at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)%0D%0A at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)%0D%0A at org.sonar.scanner.task.ScanTask.execute(ScanTask.java:48)%0D%0A at org.sonar.scanner.task.TaskContainer.doAfterStart(TaskContainer.java:84)%0D%0A at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)%0D%0A at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)%0D%0A at org.sonar.scanner.bootstrap.GlobalContainer.executeTask(GlobalContainer.java:121)%0D%0A at org.sonar.batch.bootstrapper.Batch.doExecuteTask(Batch.java:116)%0D%0A at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:71)%0D%0A at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)%0D%0A at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)%0D%0A at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)%0D%0A at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)%0D%0A at java.lang.reflect.Method.invoke(Method.java:498)%0D%0A at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)%0D%0A at com.sun.proxy.$Proxy0.execute(Unknown Source)%0D%0A at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:171)%0D%0A at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:128)%0D%0A at org.sonarsource.scanner.cli.Main.execute(Main.java:111)%0D%0A at org.sonarsource.scanner.cli.Main.execute(Main.java:75)%0D%0A at org.sonarsource.scanner.cli.Main.main(Main.java:61)

I have a maven project with groovy and java files. I ran SonarQube analyses for the project on SonarQube server when the Groovy plugin was not installed yet. Then with Groovy plugin installed, I added empty sonar-project.properties file to my project. And also <sonar.groovy.binaries>target/classes</sonar.groovy.binaries> to my pom file. Then I ran Jenkins job
with a build step
$SONAR_MAVEN_GOAL -Dsonar.host.url=$SONAR_HOST_URL and pre-build step clean package -Dmaven.test.skip=true.

The problem is that I still don't see any .groovy files on my Sonar project, which was created during the first run.

1. Shall I create a new SonarQube project to see Sonar scanner results for groovy files?
2. What has to be in sonar-project.properties, if default settings are OK for me? Can it be empty?
3. Shall I use sonar-project.properties with maven project or just properties in the .pom file?

In SonarQube we usually don't expect to measure duplication on test files. Test files are by nature very likely to look as duplicated code.

We get grvy:org.codenarc.rule.unused.UnusedVariableRule.fixed for (essentially) the following groovy script code:

import groovy.transform.Field
@Field private final String FOO = 'foo'

void f() {
    println FOO
}

It seems @pmayweg is MIA (please close this issue if I'm wrong).

My company has some interest in continue supporting this plugin and it seems I'm not alone (pinging @hypery2k, @armsargis, @pvdissel, @CCFenner, @SMUnlimited who recently showed interest, created PRs, etc.)

I'd like to propose to continue this project with broader community involvement.

@ganncamp or @henryju (or anyone else from SonarSource, please forward if not appropriate) - Can we host this plugin under the https://github.com/SonarQubeCommunity umbrella? Otherwise I would create a new organization and add everybody interested as an administrator.

What do you think?

In our report we have warnings like this:

INFO: Sensor Groovy JaCoCo [groovy]
INFO:   Checking binary directory: /home/sonar/project/target/classes
INFO: Analysing /home/sonar/project/target/jacoco.exec
INFO: Analysing /home/sonar/project/target/jacoco.exec
WARN: File not found: /executeSonarScan.groovy
WARN: File not found: /executeDocker.groovy
WARN: File not found: /loadDefaultValues.groovy

This results to the missing handling of empty package names here.

There desperately needs to be a reference application to show just how the heck to use this plugin.

... And for my purposes, I want to see that application built via gradle. A good example of what I'd at least like to see is found here for an aspectj plugin.

So when you go to the README.md there is no example on how to actually use this plugin (e.g.) in a gradle project. Historically, since at least release 1.4, there is no suggestion for the apply statement that matches up with

classpath group: 'org.sonarsource.groovy', name: 'sonar-groovy-plugin', version: '1.4'

in your buildscript block. IMHO your user community should not have to guess.

I picked 1.4 since that version is on Maven Central, whereas 1.6 is not. (Presumably because there was a Sonar business decision not to support groovy in 2019.) But whether it's 1.4 or 1.6, the problem is the same.

And given that this 1.6 release is not in Maven Central, it would help to explain how folks can down load this client-side plugin into their local maven repo, and how to configure gradle to look into that local repo to find the plugin.

For example, why let your users guess -- as I currently am -- that this article shows the solution on the "install plugin" pragmatic: i.e., Guide to installing 3rd party JARs. Esp since there's old old documentation to suggest that a server side plugin needed installation in a long distant past. It would be nice to prevent confusion here by simply spelling it out.

Then the entire README.md is moot as to what configuration -- if any -- is really required for Cobertura, JoCoCO, CodeNarc, GMetric.

Likewise, there is no CLI examples or a reference to link some documentation on sonar-scanner. At least your users should not have to hunt to find this link on sonar-scanner. But I should add that there's no real examples there either on how to run and what to expect from running sonar-scanner.

And for the time being, I will wrap my initial observations, by stating what I thought might be useful: confirming the conventions this plugin is using as to finding groovy source, groovy test code (since the sonar plug-in per se runs the tests by default), whether Junit, spock or testNG is supported, configuring where the sonar server is running (and which port its on), and how to over-ride these defaults.

Plus, it might be useful to point to documentation on how to run this scan against the latest docker image. As that's how I'm testing it.

Many organizations cannot blindly utilize OSS without reviewing the license the software is available under. Can you please identify and publicize the license under which this project is made available?
I'd humbly suggest Apache, MIT, BSD or GPLv2 as more restrictive licenses can make the project unusable (i.e. LGPL and AGPL). Thanks.

sonar.groovy.binaries is resolved only once for the root project. In a multi-module project where the property is not defined on the root module but only on leaf modules this cause missing coverage information.

SonarQube 6.7.1.35068 community
Plugins:

• SonarC# 6.5.0.3766 (csharp)
• SonarPython 1.8.0.1496 (python)
• Groovy 1.5 (groovy)
• SonarJava 5.1.1.13214 (java)
• Flex 2.3 (flex)
• SonarQube :: Plugins :: SCM :: Git 1.3.0.869 (scmgit)
• SonarXML 1.4.3.1027 (xml)
• SonarPHP 2.11.0.2485 (php)
• SonarTS 1.1.0.1079 (typescript)
• SonarQube :: Plugins :: SCM :: SVN 1.6.0.860 (scmsvn)
• SonarJS 3.2.0.5506 (javascript)

I would like to request a property sonar.groovy.reportPaths in order to override the default target/surefire-reports. If I use the property sonar.junit.reportPaths and set the value to another path, SurefireSensor [java] examines the new path. However, GroovySurefireSensor ignores the setting. This would be incredibly helpful in pipeline with several sub-project build/tests.

14:43:11.641 INFO: Sensor GroovySurefireSensor [groovy] 14:43:11.643 INFO: parsing /var/lib/jenkins/workspace/aa_marks_components_unit/target/surefire-reports ... 14:43:11.647 INFO: Sensor SurefireSensor [java] 14:43:11.649 INFO: parsing [/var/lib/jenkins/workspace/aa_marks_components_unit/build/test-results/test]

Many thanks for your time.

I'm hoping to use the sonarqube gradle plugin which, from what I can tell, uses this code to actually perform the heavy lifting. The issue I am having is this plugin's ability to leverage the gradle codenarc plugin (or how to make the pmayweg/sonar-groovy code be more configurable, especially when called from the sonarqube gradle plugin).

I have created a repo in the "final state" including a README.md that provides a simple step-by-step for how I got there. See https://github.com/kdorff/test-sonarqube

Specifically, I want to be able to run codenarc on tests as well as source AND be to specify the CodeNarc ruleset that will be used. I am able to run codenarc as expected, and I believe this plugin is seeing my report(s) (at least main.xml, probably not test.xml). I think we are both using the same codenarc (0.25.2) but this plugin doesn't understand any of the issues in the codenarc report. Output looks like:

$ ./gradlew clean codenarcMain codenarcTest sonarqube
:clean
:codenarcMain
CodeNarc rule violations were found. See the report at: file:///Users/kevi9037/save/IntelliJ/test-sonarqube/build/reports/codenarc/main.xml
:codenarcTest
CodeNarc rule violations were found. See the report at: file:///Users/kevi9037/save/IntelliJ/test-sonarqube/build/reports/codenarc/test.xml
:compileJava NO-SOURCE
:compileGroovy
:buildProperties
:processResources
:classes
:compileTestJava NO-SOURCE
:compileTestGroovy
:processTestResources NO-SOURCE
:testClasses
:test
:sonarqube
No such rule in SonarQube, so violation from CodeNarc will be ignored: ClassJavadoc
No such rule in SonarQube, so violation from CodeNarc will be ignored: FileEndsWithoutNewline
No such rule in SonarQube, so violation from CodeNarc will be ignored: NoDef
No such rule in SonarQube, so violation from CodeNarc will be ignored: TrailingWhitespace
No such rule in SonarQube, so violation from CodeNarc will be ignored: TrailingComma
No such rule in SonarQube, so violation from CodeNarc will be ignored: SpaceAroundMapEntryColon
No such rule in SonarQube, so violation from CodeNarc will be ignored: UnnecessaryReturnKeyword
No such rule in SonarQube, so violation from CodeNarc will be ignored: SpaceBeforeOpeningBrace
No such rule in SonarQube, so violation from CodeNarc will be ignored: UnnecessaryGString
Metric 'lines' is an internal metric computed by SonarQube. Provided value is ignored.
Metric 'test_success_density' is an internal metric computed by SonarQube. Provided value is ignored.

In the sonar scanner log I see the messages

INFO: Sensor Groovy JaCoCo [groovy]
...
WARN: File not found: util/JenkinsErrorRule.groovy
WARN: File not found: util/BaseTest.groovy
WARN: File not found: steps/DeployTest.groovy

I run with the following settings:

sonar.sources=src,vars
sonar.tests=test

So the above files are located in the test folder but are not considered by JaCoCo. If I add the test folder from sonar.tests to sonar.sources the GroovySurefireSensor is complaining about it.

Is it correct that JaCoCo considers only files of Type.MAIN here and not also Type.TEST?