codeconsole commented on PR #15964: URL: https://github.com/apache/grails-core/pull/15964#issuecomment-4941053135
The functional-test failures were caused by the mutual-exclusion fail-fast from ba2c2ec2: it turns out a combined classpath is not a freak misconfiguration but the standard state for SiteMesh 2 applications — grails-sitemesh3 arrives transitively via `grails-dependencies-starter-web`, so declaring `grails-layout` puts both on the classpath (as half a dozen apps in grails-test-examples do, e.g. `spring-dependency-management`). 32bb99760f keeps the mutual-exclusion *contract* but tolerates co-presence the way those applications already relied on: SiteMesh 2 keeps decorating and this module stands down — one `isSiteMesh2Present()` classpath check gating the definition post-processor, the bean post-processor, and the `grailsRenderViewMutator` registrar registration (which would otherwise displace SM2's mutator via registrar name-conflict precedence, the regression flagged earlier). `Sitemesh3EnvironmentPostProcessor` warns loudly with exclusion instructions, and the tolerance is documented as subject to removal. Escalating to a hard fail-fast would need the in-tree apps fixed (exclude grails-sitemesh3 from the starter) and is really a separate policy decision — happy to prepare that as a follow-up if that's the direction you want. Verified locally: `:grails-sitemesh3` suite + checkstyle/codenarc, whole-repo compile, and `--rerun-tasks` integration tests for `spring-dependency-management` (the failing app), `mail` (also combined-classpath), `app1`, and `mongodb-base`. -- 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]
