I am encountering an issue when running a Jenkins pipeline that involves SonarQube (9.9) analysis. The job is failing on a Jenkins slave machine that runs Java 8. Below is the error message:
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121:sonar (default-cli) on project BillDeskIntegrationService:
Execution default-cli of goal org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121:sonar failed:
Unable to load the mojo 'sonar' in the plugin 'org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121' due to an API incompatibility:
org.codehaus.plexus.component.repository.exception.ComponentLookupException: org/sonarsource/scanner/maven/SonarQubeMojo has been compiled by a more recent version of the Java Runtime
(class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
The error indicates that the Sonar Maven plugin requires Java 11 (class file version 55.0), but the Jenkins slave is running Java 8, which only supports class file versions up to 52.0.
I am hesitant to upgrade the entire Jenkins slave to Java 11 because it may introduce compatibility issues with other Maven builds that are dependent on Java 8.
My SonarQube 9.9 runs in a separate instance with Java 17.
Additionally, I have another Jenkins slave with both Java 8 and Java 11 installed. Is there a way to configure my Jenkins pipeline or Maven job to dynamically select the appropriate Java version based on the tool (e.g., Java 11 for SonarQube analysis and Java 8 for other parts of the build)?
14:13:19 [WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:Maven-surefire-plugin:2.19.1:
Plugin org.apache.maven.plugins:Maven-surefire-plugin:2.19.1 or one of its dependencies could not be resolved:
Failure to find org.apache.maven.plugins:Maven-surefire-plugin:jar:2.19.1 in https://artifactory.bfsgodirect.com/repository/BFDL_PROXY/
was cached in the local repository, resolution will not be reattempted until the update interval of BFDL_PROXY has elapsed or updates are forced
...
14:13:19 [INFO] --- sonar-maven-plugin:4.0.0.4121:sonar (default-cli) @ BillDeskIntegrationService ---
...
14:13:20 [ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121:sonar (default-cli) on project BillDeskIntegrationService:
Execution default-cli of goal org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121:sonar failed:
Unable to load the mojo 'sonar' in the plugin 'org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121' due to an API incompatibility:
org.codehaus.plexus.component.repository.exception.ComponentLookupException: org/sonarsource/scanner/maven/SonarQubeMojo has been compiled by a more recent version of the Java Runtime
(class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
14:13:20 [ERROR] -----------------------------------------------------
I would appreciate any advice on how to resolve this issue without disrupting the current setup.
I have both Java 8 and Java 11 present on the same Jenkins slave but still face the same error when running the pipeline.
Is it possible to run two different Java versions in the same pipeline script?
How can I fix the SonarQube 9.9 compatibility with the Java 8 slave?
Your entire Maven build must run using Java 11 or above. You can’t run parts of the Maven build with Java 8 and other parts with Java 11. However, what you can do is do 2 builds: one with Java 8 that doesn’t include SonarQube, and one with Java 11 that runs only SonarQube. To use existing test and coverage reports it’s advised to run this after the regular build, and without clean.
To get this to work you need to have Java 11 configured as tool inside Jenkins. For me the easiest way is to include an installer (I prefer Adoptium), that way the JDK will be installed if needed, separate from the JDK that’s running Jenkins.
Assuming you have a (multibranch) pipeline job, the usual first step is to define global tools:
pipeline {
...
tools {
jdk 'jdk-8' // or whatever the identifier is
maven 'maven-3' // or whatever the identifier is
}
...
}
This makes java and mvn available throughout the pipeline. This is where we now have to deviate from, but only for the part that needs a different version.
In the build for SonarQube you need to define a different tool. If available you can use withMaven:
// The publisherStrategy prevents build artifacts to be added as Jenkins artifacts
withMaven(jdk: 'jdk-11', maven: 'maven-3', publisherStrategy: 'EXPLICIT') {
...
}
If that’s not available (due to a missing plugin), you can still do it using tool and withEnv:
withEnv(["JAVA_HOME=${tool('jdk-11')}"]) {
// $JAVA_HOME is now that of Java 11, so Maven will use Java 11
// To run a different Maven that's also possible:
sh "${tool('maven-3')}/bin/mvn --version"
}
The tool function installs the tool if needed, and returns its base path. I’ve used it quite often in configurable pipelines where the Java version wasn’t fixed.