Sonar scanner gradle 7.3.0 - ClassNotFoundException: nl.altindag.sude.LoggerFactory

SonarQube Server / Community Build
1

When running the :sonar task with the Gradle plugin org.sonarqube:7.3.0, the build fails with a ClassNotFoundException for nl.altindag.sude.LoggerFactory.

Stack trace

Caused by: java.lang.NoClassDefFoundError: nl/altindag/sude/LoggerFactory
    at nl.altindag.ssl.SSLFactory.<clinit>(SSLFactory.java:89)
    at org.sonarsource.scanner.lib.internal.http.HttpClientFactory.configureSsl(HttpClientFactory.java:85)
    at org.sonarsource.scanner.lib.internal.http.HttpClientFactory.create(HttpClientFactory.java:65)
    at org.sonarsource.scanner.lib.internal.http.ScannerHttpClient.init(ScannerHttpClient.java:53)
    at org.sonarsource.scanner.lib.ScannerEngineBootstrapper.bootstrap(ScannerEngineBootstrapper.java:147)
    at org.sonarqube.gradle.SonarTask.run(SonarTask.java:604)
Caused by: java.lang.ClassNotFoundException: nl.altindag.sude.LoggerFactory
    at org.gradle.internal.classloader.VisitableURLClassLoader$InstrumentingVisitableURLClassLoader.findClass(VisitableURLClassLoader.java:189)

Additionally, sude has moved from nl.altindag:sude to io.github.hakky54:sude on Maven Central. Users with strict Artifactory mirrors that don’t proxy nl.altindag will not find the artifact at all, compounding the issue — even if they attempt to manually supply the dependency.

Root cause

The sonar-scanner-java-library bundled with this plugin includes nl.altindag.ssl.SSLFactory (from sslcontext-kickstart). SSLFactory uses nl.altindag.sude.LoggerFactory for logging. However, sude is declared as optional in sslcontext-kickstart’s POM, so Gradle does not resolve it transitively.

This means sude is never placed on the buildscript classpath, and the first call into SSLFactory throws NoClassDefFoundError.

Environment

  • Plugin: org.sonarqube version 7.3.0.8198

  • Gradle: 9.2

  • Java: 21

Expected behavior

Either:

  1. sude is bundled/shaded into the scanner library JAR so it requires no external resolution, or

  2. sude is declared as a non-optional compile dependency so Gradle resolves it transitively and from correct path within maven repository

Can you please fix that?

Workaround

I’m trying explicitly add sude to the buildscript classpath:

buildscript {
    dependencies {
        classpath("nl.altindag:sude:2.0.2")
    }
}

This requires the artifact to be available in your build’s repositories (which I’m struggling with, because of our enterprise environment).

I will update this post once I get workaround working.

2

Hi,

Welcome to the community and thanks for this report!

Can we get a full --info log starting from the analysis command itself?

 
Thx,
Ann

3

Sude logging API is bundled with Ayza SSL library version 10.0.1 on words. It is included as a transitive dependency so it should technically automatically be bundled with Sonar

4

But it is not. I’m having the same issue with 5.7.0.6970 version for maven

5

Hi @cvgaviao,

This thread is about a problem with SonarScanner for Gradle. Are you saying you’re getting exactly the same error running SonarScanner for Maven?

And if so, can you provide an analysis log?

The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.

This guide will help you find them.

 
Ann

6

@ganncamp I see someone solved it in a different way see here for their workaround: Fix Sonar scan: pin sude dependency for sonar-maven-plugin by vpaturet · Pull Request #248 · entur/superpom · GitHub

He added the following comment:

sonar-scanner-java-library → ayza → sude, but ayza declares sude
without a version (it is managed only in ayza-parent), so the version
is not applied in the plugin classpath realm and sude is dropped,
causing ClassNotFoundException: nl.altindag.sude.LoggerFactory when the
scanner initialises its HTTPS client. Pin it explicitly until SonarSource
fixes the scanner dependency chain (still broken in scanner-maven 5.7.0).

Do you think that is the issue @ganncamp I can adjust the pom and publish a new version with explicite version in the related child pom of the ayza library

7

Hi @Hakky54,

I’m looking for a full, info-level analysis log. I cannot proceed without one.

 
Ann