borinquenkid commented on PR #15341:
URL: https://github.com/apache/grails-core/pull/15341#issuecomment-5009746335
*Posted with assistance from Claude Code (Anthropic's CLI agent) — I
actually ran the build and decompiled the plugin jar to verify the finding
below before posting.*
Since this has been quiet since April, I spent some time actually running it
to help move it along.
**The settings-plugin approach here is correct** and matches what was asked
for back in February — I ran `./gradlew :grails-core:projectHealth` on this
branch and it works end-to-end: the `com.autonomousapps.build-health` settings
plugin auto-applies to `:grails-core` without any per-module `build.gradle`
changes, and it genuinely caught a real duplicate-class conflict between
`org.slf4j:jcl-over-slf4j` and `org.springframework:spring-jcl` (both provide
`org.apache.commons.logging.Log`/`LogFactory`).
**One scope issue before this can merge, though.** I decompiled
`dependency-analysis-gradle-plugin-3.5.1.jar` to check the issue-configuration
API, and DAGP has granular per-issue-type severity handlers
(`onUnusedDependencies`, `onIncorrectConfiguration`, `onCompileOnly`,
`onRuntimeOnly`, `onDuplicateClassWarnings`, etc.), not just `onAny`. The
current config in `gradle/dependency-analysis.settings.gradle` uses:
```groovy
dependencyAnalysis {
issues {
all {
onAny {
severity 'fail'
}
}
}
}
```
`onAny` escalates *every* issue category to a hard failure, not just
duplicate classes. When I ran `projectHealth`, `:grails-core` failed not only
on the real duplicate-class hit but also on 5 unused dependencies, 7 "should be
declared directly" transitive deps, 2 api/implementation misconfigurations, 2
runtime-only candidates, and 1 compile-only candidate — all pre-existing, all
unrelated to the Maven-Hijack/duplicate-class goal this PR is scoped to. DAGP's
default severity is `warn`, so this config is what turns all of that into a
build breaker. Merging as-is means `:grails-core` CI goes red immediately, and
likely every other module once this rolls out further, for reasons that have
nothing to do with duplicate classes — a much bigger cleanup than this PR's
stated scope.
The fix is narrow:
```groovy
dependencyAnalysis {
issues {
all {
onDuplicateClassWarnings {
severity 'fail'
}
onAny {
severity 'warn'
}
}
}
}
```
That scopes the hard failure to the actual guard this PR is for, and leaves
the rest of DAGP's advice as non-blocking (which can be tightened separately
later if wanted). Happy to help verify once that's in.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
