Skip to content

Exclude logback-classic from generate-configprops plugin dependency - #687

Closed
ryanjbaxter wants to merge 1 commit into
mainfrom
fix/generate-configprops-logback-conflict-main
Closed

ryanjbaxter wants to merge 1 commit into
mainfrom
fix/generate-configprops-logback-conflict-main

Conversation

@ryanjbaxter

@ryanjbaxter ryanjbaxter commented Sep 17, 2026

Copy link
Copy Markdown
Contributor

Summary

Preemptive main counterpart to #686.

spring-cloud-config's 5.0.x branch hit an intermittent/reproducible CI failure in the generate-configprops exec-maven-plugin execution (https://github.com/spring-cloud/spring-cloud-config/actions/runs/35267039454/job/105356701618):

java.lang.NoSuchMethodError: 'java.lang.ClassLoader ch.qos.logback.core.util.Loader.systemClassloaderIfNull(java.lang.ClassLoader)'

spring-cloud-build-docs is consumed by this execution via the jar-with-dependencies classifier — a shaded uber jar that already bundles its own, self-consistent logback-classic/logback-core pair. However, exec-maven-plugin's includePluginDependencies classpath merge also separately resolves the dependency's own unversioned logback-classic (landing on an old, incompatible version), adding a second, conflicting copy of these classes to the classpath. Which copy wins for which class depends on classpath ordering, which isn't guaranteed stable across builds — hence the intermittent failures on 5.0.x.

main has the exact same generate-configprops execution structure, so it's exposed to the same risk even though it hasn't reproduced there yet.

Fix

Exclude ch.qos.logback:logback-classic (which transitively pulls logback-core) from the spring-cloud-build-docs plugin dependency declaration in the generate-configprops execution, so the classpath relies solely on the matched pair already bundled in the uber jar. Same change as #686.

Test plan

  • CI passes for this PR

spring-cloud-build-docs is consumed via the jar-with-dependencies
classifier, which already bundles a matched logback-classic/
logback-core pair. exec-maven-plugin's includePluginDependencies
classpath merge also separately resolves the dependency's own
unversioned logback-classic, landing an old, incompatible
logback-classic/logback-core split across the uber jar and the
separately-resolved thin jar. Depending on classpath ordering this
can intermittently fail generate-configprops with:

  java.lang.NoSuchMethodError: 'java.lang.ClassLoader
  ch.qos.logback.core.util.Loader.systemClassloaderIfNull(java.lang.ClassLoader)'

Excluding logback-classic (and transitively logback-core) forces the
classpath to rely solely on the bundled, self-consistent pair. Same
fix as #686 on 5.0.x, applied here preemptively since main has the
identical fragile setup.
@ryanjbaxter
ryanjbaxter force-pushed the fix/generate-configprops-logback-conflict-main branch from e337b3e to feb588c Compare September 17, 2026 20:25
@ryanjbaxter

Copy link
Copy Markdown
Contributor Author

Closing — this will be merged forward from 5.0.x (#686) instead.

@ryanjbaxter
ryanjbaxter deleted the fix/generate-configprops-logback-conflict-main branch September 17, 2026 20:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant