Centralizing Gradle Logic

[jdaugherty]

@matrei @jamesfredley

We agreed a few weeks ago to start migrating to internal gradle plugins in buildSrc. This is my initial work to refactor the sbom & publish configuration into a centralized location. Note: since we're using 3 separate, composite gradle builds, I had to refactor into a 'build-logic' build that's then included. This is similar to how groovy manages their build.

Some highlights:

1. I used the plugin approach instead of gradle scripts to take advantage of CompileStatic
2. ordering is now solved by using withPlugin() so the logic is only applied when needed
3. I looked into validating the bom dependencies, but this isn't practical. I made the boms continue to not generate an sbom since they only contain constraints
4. I've restored the jar behavior for the starter projects; the original reason I removed it is because we're not publishing jar files for grails-bom, and all we really need is a pom. After experimenting, I realized we are publishing the sbom now so we probably should keep the jar.
5. Some of the sbom plugin migration was not converted to compilestatic (this is a future todo)

I intend to restructure the rest of our scripts into this format and make them order agnostic using withPlugin() like these. What are the initial thoughts on this approach?

[jdaugherty]

@matrei the more I look at the codeStyle work you did, I think we should create a plugin that exists in another git repo - then apply that plugin across all of the apache/grails projects. What are your thoughts on this?

If we did that, then we could also apply it to our gradle plugins in the build-logic project ...

[jdaugherty]

@matrei @jamesfredley And one more thought: I'm strongly considering moving the publish artifacts task logic & the checksum logic into the grails-publish plugin. This would help eliminate the duplication across all of the projects. What are your thoughts on this?