At this time the build script is based on applying various other Gradle Groovy scripts. Plugins applied at various places in the build scripts. The root build script also uses a mixed bag of plugin declaration, e.g. classpath entries in the build script, but we have now a version catalog file that can serve this purpose.

This approach is a bit old, it was the best thing we could do 10 years ago in the early days of Gradle. Nowadays the preferred approach to share configuration between subprojects is to use convention plugins.

For example in Gradle 8.10, a gradle init with the app template, will create a buildSrc folder with convention plugins, e.g that configure the java conventions, etc.
Also, other modern Gradle projects now follow that recommended approach, e.g. open-telemetry.

We should do the same.

Implications

• Porting existing logic to Kotlin DSL, and tailor it to "convention plugins". Also, they are a few minor API differences with Groovy DSL.
• Build bugs might be introduced while doing so.

Benefits

• Standard way of declaring the build.
• Better IDE assistance with Kotlin.
• In doing so this gives an opportunity to review or audit the build script.
• Hopefully easier reusability.
• Improved configuration segregation between root project and mockito-core.