How to correctly configure the attribute “sonar. Java. Binaries”?

We use sonarqube 5.1 2. Use ant runner 2.2 and Java plugin 3.12 for analysis I can successfully analyze my project I just keep getting this error:

Java bytecode has not been made available to the analyzer. The org.sonar.java.bytecode.visitor.DependenciesVisitor@d678716,org.sonar.java.checks.unused.UnusedPrivateMethodCheck@58e28efd,CycleBetweenPackages rule are disabled.

So I need to configure my sonar java. Binaries and sonar java. test. Binaries attribute (in http://docs.sonarqube.org/display/PLUG/Java +After plugin + and + bytecode)

I think I did it right:

<property name="project.dir" value="${basedir}/xalg.prj/h3_service_fo" />   
<property name="sonar.java.binaries" location="${project.build.dir}/classes/main" />
<property name="sonar.java.test.binaries" value="${project.build.dir}/classes/test" />

Which of the following valid directories resolves to the above attributes:

basedir=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj
project.dir=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo
sonar.java.binaries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\xalg.prj\\h3_service_fo\\build\\classes\\main
sonar.java.test.binaries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/build/classes/test

But I've been:

Java bytecode has not been made available to the analyzer. The org.sonar.java.bytecode.visitor.DependenciesVisitor@d678716,CycleBetweenPackages rule are disabled.

And for my life, I can't figure out what I need to give to sonar java. Binaries and sonar java. test. The value of the binaries property I even tried using sonar Binaries, which gives me the following output:

Binary dirs: xalg.prj/h3_service_fo/build/classes

I didn't use sonar java. Binaries or sonar java. test. binaries. I also got:

JavaClasspath initialization...
sonar.binaries and sonar.libraries are deprecated since version 2.5 of sonar-java-plugin,please use sonar.java.binaries and sonar.java.libraries instead

This is expected for abandoned property But use sonar java. For binaries attribute, I didn't get the "binary dirs" line in my log

Use sonar java. binaries:

Language is forced to java
Load rules
Load rules (done) | time=761ms
Code colorizer,supported languages: cs,plsql
Initializers : 
Base dir: D:\appl\BuildAgent\work\H3\src.prj\java.prj
Working dir: D:\appl\BuildAgent\work\H3\src.prj\java.prj\.sonar
Source paths: xalg.prj/h3_service_fo/src/main/java
Test paths: xalg.prj/h3_service_fo/src/test/java
Source encoding: windows-1252,default locale: en_US
Index files

Use sonar binaries:

Language is forced to java
Load rules
Load rules (done) | time=736ms
Code colorizer,plsql
Initializers : 
Base dir: D:\appl\BuildAgent\work\H3\src.prj\java.prj
Working dir: D:\appl\BuildAgent\work\H3\src.prj\java.prj\.sonar
Source paths: xalg.prj/h3_service_fo/src/main/java
Test paths: xalg.prj/h3_service_fo/src/test/java
Binary dirs: xalg.prj/h3_service_fo/build/classes
Source encoding: windows-1252,default locale: en_US
Index files

I also checked the source code of sonarqube, sonarqube Java plug-in and sonarqube scanner to find an instance of "Java bytecode has not been provided to the analyzer" Or sonar java. binaries. I'm in sonar java. Many contents have been found on binaries, but "Java bytecode has not been provided to the analyzer" So I don't know what conditions will cause errors

I'm still in sonar java. The following permutations were attempted on binaries:

<property name="sonar.java.binaries" location="${project.build.dir}/classes" />
<property name="sonar.java.binaries" location="${project.build.dir}/classes/main/nl" />

But it didn't do anything

Strangely enough, squid seems to solve the classpath problem well:

----- Classpath analyzed by Squid:
D:\appl\BuildAgent\work\H3\src.prj\java.prj\xalg.prj\h3_service_fo\build\classes\main

So, what did I miss? What on earth did I do wrong? Thank you in advance

Update 2016-09-08: delete the whole log, and the post becomes very long

(I think) subset of related paths:

project.build.dir=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/build
project.dir=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo
project.src.dir=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/src

sonar.dir=D\:/appl/sonarqube-5.1.2
sonar.working.directory=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\.sonar
sonar.projectBaseDir=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj

sonar.jacoco.reportPath=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/build/jacoco/test.exec
sonar.junit.reportsPath=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/build/test-results

sonar.sources=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/src/main/java
sonar.java.binaries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\xalg.prj\\h3_service_fo\\build\\classes\\main

sonar.java.libraries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/_deploy/*.jar,D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/_repos/lib/*.jar,D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/_repos/provided/*.jar

sonar.tests=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/src/test/java
sonar.java.test.binaries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/build/classes/test
sonar.java.test.libraries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/_deploy/*.jar,D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/_repos/provided/*.jar

The format of the path is exactly the same as that of my post Is it possible that sonar ant runners cannot find paths with backslashes and slashes?

Update on September 16, 2016: delete the entire log, and the post becomes very long

(I think) subset of related paths:

project.build.dir=xalg.prj\\\\h3_service_fo\\\\build
project.dir=xalg.prj\\\\h3_service_fo
project.src.dir=xalg.prj\\\\h3_service_fo\\\\src

sonar.dir=D\:\\\\appl\\\\sonarqube-5.1.2
sonar.working.directory=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\.sonar
sonar.projectBaseDir=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj

sonar.jacoco.reportPath=xalg.prj\\\\h3_service_fo\\\\build\\\\jacoco/test.exec
sonar.junit.reportsPath=xalg.prj\\\\h3_service_fo\\\\build\\\\test-results

sonar.sources=xalg.prj\\\\h3_service_fo\\\\src\\\\main\\\\java
sonar.java.binaries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\xalg.prj\\h3_service_fo\\build\\classes\\main
sonar.java.libraries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\\\_deploy\\\\*.jar,D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\\\_repos\\\\lib\\\\*.jar,D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\\\_repos\\\\provided\\\\*.jar

sonar.tests=xalg.prj\\\\h3_service_fo\\\\src\\\\test\\\\java
sonar.java.test.binaries=xalg.prj\\\\h3_service_fo\\\\build\\\\classes\\\\test
sonar.java.test.libraries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\\\_deploy\\\\*.jar,D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\\\_repos\\\\provided\\\\*.jar

Some paths become relative, but I think this is because teamcity changes ant files to files in SVN sonar. java. Binaries is absolute. It must point to the correct directory

But I still get this mistake:

09:17:52.299 INFO  - Java Main Files AST scan done: 1579 ms
09:17:52.301 INFO  - 2/2 source files have been analyzed
09:17:52.305 WARN  - Java bytecode has not been made available to the analyzer. The org.sonar.java.bytecode.visitor.DependenciesVisitor@757a48f9,org.sonar.java.checks.unused.UnusedPrivateMethodCheck@1adf492b,CycleBetweenPackages rule are disabled.

The classpath is still well interpreted:

[sonar:sonar] 09:17:51.971 DEBUG - ----- Classpath analyzed by Squid:
[sonar:sonar] 09:17:51.972 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\xalg.prj\h3_service_fo\build\classes\main
[sonar:sonar] 09:17:51.973 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\batch.daemon.jar
[sonar:sonar] 09:17:51.974 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\buildinfo.jar
[sonar:sonar] 09:17:51.975 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h2_shared.jar
[sonar:sonar] 09:17:51.975 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_generator.jar
[sonar:sonar] 09:17:51.976 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_loadtest.jar
[sonar:sonar] 09:17:51.977 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_common.jar
[sonar:sonar] 09:17:51.977 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xalg.jar
[sonar:sonar] 09:17:51.978 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xalg_dao.jar
[sonar:sonar] 09:17:51.979 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xalg_mappers.jar
[sonar:sonar] 09:17:51.979 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xalg_procedures.jar
[sonar:sonar] 09:17:51.980 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xcare.jar
[sonar:sonar] 09:17:51.981 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xcare_dao.jar
[sonar:sonar] 09:17:51.982 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xcare_mappers.jar
[sonar:sonar] 09:17:51.982 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xcare_procedures.jar

Do sonar ant runners have problems escaping backslashes?

Solution

This is what I use. It works

sonar-scanner -Dsonar.projectKey=projectName -Dsonar.gitlab.commit_sha=$CI_BUILD_REF -Dsonar.gitlab.ref_name=$CI_BUILD_REF_NAME -Dsonar.sources=directory\src\ -Dsonar.java.binaries=.build\libs\

You need to put sonar java. Binaries points to the directory containing the jar I won't try wildcards and file extensions. It's not the same thing You need a directory as an argument, not a regular expression for a file

I don't know everything about sonar scanners, but my configuration works

Bringing my example into context, I use it in the gitlab runtime pipeline Your double backslashes should be OK, but you can always replace them as forward slashes in the configuration file

The content of this article comes from the network collection of netizens. It is used as a learning reference. The copyright belongs to the original author.
THE END
分享
二维码
< <上一篇
下一篇>>