Only one issue for squid:MaximumInheritanceDepth detected

323 views
Skip to first unread message

goroll...@gmail.com

unread,
Mar 20, 2018, 2:46:31 AM3/20/18
to SonarQube
Hi,

we have a rather large code base and several classes which have more than five parents. However, in SonarQube only one issue is detected for squid:MaximumInheritanceDepth. Initially, we changed to the rule configuration to exclude java.lang.* (because of findings on extended exceptions). Right now we use the default configuration: at most 5 parents, no filters.
We have a second SonarQube project for testing that is a subset of our main project, with the same quality profile. There, the same issue is found on the same class.
SonarLint in eclispe finds issues for the rule correctly and uses the correct configuration from the server.
In the log files with level TRACE I couldn't find any hint as to the problem.

Versions:
SonarJava: 5.1 (build 13090)
SonarQube: 6.7.2.37468
SonarLint: 3.3.1.201712071600

Regards,
Oliver

Nicolas Peru

unread,
Mar 20, 2018, 3:39:43 AM3/20/18
to goroll...@gmail.com, SonarQube
Hi Oliver, 

SonarJava relies on the bytecode to compute the inheritance tree. The fact that it works properly in SonarLint but not in SonarQube tends to point to a problem of configuration of the analysis when you run it for SonarQube.
Which scanner do you use ? if not scanner for maven, how are the sonar.java.binaries and sonar.java.libraries properties filled when you run your analysis ? 

Cheers, 

--
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/f1049fe7-10be-496e-90c7-98259e61eb19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Nicolas Peru | SonarSource

goroll...@gmail.com

unread,
Mar 20, 2018, 4:59:55 AM3/20/18
to SonarQube
Sources and binaries are configured like

sonar.sources=projects/../plugins/../src/..
sonar.java.binaries=projects/../plugins/../bin/..

For the libraries we didn't configure anything yet, but we're looking into it.

Nicolas Peru

unread,
Mar 20, 2018, 5:16:24 AM3/20/18
to goroll...@gmail.com, SonarQube
Hi, 

so if the libraries are not configured then the inheritance tree cannot be computed, hence the difference of behavior with SonarLint (as SonarLint has all the information from the IDE to automagically configure those). 

Cheers, 


For more options, visit https://groups.google.com/d/optout.

goroll...@gmail.com

unread,
Mar 20, 2018, 5:54:54 AM3/20/18
to SonarQube
Well, not exactly. The missing library configuration explains why we don't get issues if we inherit from library classes. But we have several cases where only counting our own classes the inheritance tree is more than five classes deep. Are the binaries for all classes in the hierarchy necessary?

Nicolas Peru

unread,
Mar 20, 2018, 6:29:29 AM3/20/18
to goroll...@gmail.com, SonarQube
Hi, 

if the classes in inheritance are not from the same module that might explain the problem (ie from a analyzer perspective they might be seen as libraries). 
Anyhow, please first configure your project properly with sonar.java.libraries and let us know if the issue persists.

To answer to your last question : yes. if binaries are not provided, symbol is not found and inheritance tree computation cannot carry on.

Cheers, 



For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages