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