build: guard against duplicate classes using dependency analysis plugin

[sanjana2505006]

This PR introduces the Dependency Analysis Gradle Plugin (DAGP) to the build system to identify and guard against duplicate classes. This addresses the security risks associated with "Maven-Hijack" type attacks and helps ensure deterministic runtime behavior by preventing multiple dependencies from providing the same fully qualified class names.

Key Changes:

• Applied the com.autonomousapps.dependency-analysis plugin (v3.5.1) to the root project.
• Enabled the plugin specifically for the :grails-core module to provide a targetted security guard for the main codebase.
• Configured global issue severity to fail in the dependencyAnalysis block to ensure any detected duplicates break the build.

Verification: Ran ./gradlew :grails-core:projectHealth, which successfully caught an existing duplicate class conflict in the :grails-core module (between jcl-over-slf4j and spring-jcl). This confirms the guard is active and effective.

This PR fixes #15329

[jdaugherty]

I appreciate the PR for this but the examples show this as a settings plugin. We also have 4 separate gradle projects that use composite builds to combine into one (technically forge) so this change is incomplete. We also need to spend time testing this.

Can you please hold off on implementing newly opened tickets in the future? Or at least check before proceeding? This is one of those tickets that needed more investigation. While that plugin is probably the right immediate solution, we haven't discussed this in the weekly yet.

[sanjana2505006]

@jdaugherty Thank you for the context, I appreciate you explaining the broader setup and the concerns around the composite builds.
That makes sense, and I agree this needs more discussion and testing before moving forward. I didn’t fully factor in the impact across the other Gradle projects.
I’ll pause further work on this and wait for direction after it’s discussed in the weekly. Going forward, I’ll make sure to check in before proceeding on newly opened tickets that may need deeper investigation.

Thank you again for the guidance.

[jdaugherty]

I am going to convert this review back to a draft since this isn't complete.

[sanjana2505006]

Hello @jdaugherty, just checking in on the status of this PR. I understand it was moved to draft for further discussion and testing, so I wanted to ask if there are any updates or if anything is expected from my side.

I’m happy to make any changes if required. Thank you!

[jdaugherty]

Hi @sanjana2505006 for now this plugin seems like an ok approach, but your implementation doesn't meet our needs nor our standards.

One of the major build rules we have after our experience in refactoring the build is to use composition. This means we never define project specific configuration in the root build config. The proper way to configure this plugin is to have a convention plugin under build-logic, and apply that plugin to every gradle project in our build.

However, in the case of this plugin, such support has already been added via a settings plugin. So we should just adopt the settings plugin instead of the project based configuration. Remember: the grails-core build is a composite build. There are 4 gradle projects in the repo: build-logic, grails-gradle, grails-core (the root repo path), and grails-forge. Every one of these projects has a settings.gradle. We need to apply this plugin to each of these then.

We also need to configure the plugin for each of these project - and that logic should be shared in a single gradle file.

Can you please update your PR to make use of the settings plugin, and to centralize the configuration? Let's start there and then we can take a further review.

[sanjana2505006]

Hello @jdaugherty,
Thank you for pointing that out, that makes total sense!
I've updated the PR to use the settings plugin approach and centralized the config.
Specifically:

• I removed the project-level config from the root build.gradle.
• I created a shared config script at gradle/dependency-analysis.settings.gradle
• I added the com.autonomousapps.build-health plugin to all 4 settings.gradle files (root, build-logic, grails-gradle, and grails-forge) and applied the shared script.
  Let me know if this looks better so we can get it out of draft!

[jdaugherty]

@sanjana2505006 instead of checking in a zip file, you can drag and drop the single page guides into a comment so we can easily access them.

[sanjana2505006]

before-single.html
after-single.html

@jdaugherty Here are the before and after single-page guides, please review it and let me know your feedbacks