Thanks for the followup from the old mailing list!
In your example, can you specify what is the helper object?
Without its declaration, it seems to me that as is this code won’t compile. If it does not compile, then the analyzer is not able to rely on bytecode to resolve types and references for objects outside the current file… leading to an unresolved constructor.
thanks for the analysis. I think I found the issue. I did not provide a valid path to the sonar.java.binaries / did not compile the classes properly. So your hint concerning the bytecode seems correct. For completeness an updated example:
Parameters:
package com.example;
import com.other.Helper;
public enum Parameters
{
A("a", Helper.a, Boolean.FALSE)
, B("b", Helper.b, Boolean.FALSE)
, C("c", Helper.b, Boolean.FALSE)
;
private final String param;
private final String param2;
private final Boolean param3;
private Parameters(final String paramName, final String param2, final Boolean param3)
{
this.param = paramName;
this.param2 = param2;
this.param3 = param3;
}
}
Helper:
package com.other;
public class Helper {
public static final String a="a";
public static final String b="b";
}
Hi michael,
Yes, providing the bytecode solved the problem in the provided example. I didn’t have time to test with the real code, but i suppose it’s the same and we can close this topic.
@Michael@rompic I have a followup question regarding this issue.
I am using sonarqube scanner 2.4 to run the analysis against the codebase with gradle.
I have a scenario where a similar class referenced here as “Helper” that is used in an enum definition is imported from a jar as a dependency in gradle. In such a case, any pointers on how to provide the right value for the field sonar.java.libraries so that the sonar run can get the bytecode from these external jars?
In theory, the SonarScanner for Gradle should do that by itself. If the issue persist, please open a new thread detailing your case, and your project setup.
