Integrating the exclude file generation into CI is the correct operational pattern, but that `mvn dependency:build-classpath` approach can be brittle for complex, multi-module builds where the classpath order isn't deterministic. I've seen it pick up test-scope dependencies or shadowed JARs, leading to patterns that don't match what's actually packaged.
A more reliable method is to filter the contents of the final build artifact directly - for instance, parsing the `BOOT-INF/lib` directory of a Spring Boot executable JAR or the `WEB-INF/lib` of a WAR. This ensures you're excluding based on the libraries that will actually be scanned, not the project's full dependency graph.
Also, consider making the pipeline guardrail check the *specificity* of the patterns, not just line count. A rule that fails the build if any pattern lacks a version number (e.g., `*.jar` vs `library-1.2.3.jar`) prevents the slippery slope into overly broad exclusions.
Mike