Gradle Kotlin DSL build script

[tmohme]

Testing Problem

It does not solve any particular testing problem ;)

Suggested Solution

If you are interested in having type-safe Kotlin DSL build scripts, I would try to convert the existing ones (plus changing the structure to avoid cross-project configuration) in a PR.

Discussion

Structurally, the result would look similar to what is described at https://docs.gradle.org/current/samples/sample_building_kotlin_applications_multi_project.html (especially the buildSrc).

[jlink]

@tmohme Thanks for the suggestion. I prefer the Groovy syntax of Gradle, but that's just a personal preference given my Groovy history. I have the feeling that it gives me a bit more leeway and is less verbose in some cases.

But what do you mean by "plus changing the structure to avoid cross-project configuration"? That sounds interesting.

[tmohme]

In the "early days" of Gradle, using "subprojects {}" and "allprojects {}" were the only means to share build logic between Subprojects.
Since a few major releases there is another, now recommended approach: Using convention plugins.
See https://docs.gradle.org/current/userguide/sharing_build_logic_between_subprojects.html#sec:convention_plugins_vs_cross_configuration
From my experience, I can confirm the described problems with cross project configuration and I had no issues with the convention plugin approach (yet).

[jlink]

This make sense - even if the Gradle documentation requires quite some hopping to understand how it works.

@tmohme If you’re willing to start with convention plugins and keep the Groovy DSL (at least in the beginning) I’d be more than happy.

[vlsi]

I recently migrated https://github.com/allure-framework/allure-gradle to the idiomatic structure, and I incline to like that structure (it is literally the same as the one used by Gradle itself)

The only bit I would like to do slightly different is to name build-logic as allure-gradle-build-logic since currently Gradle does not support composite builds where multiple builds have their own build-logic module (see gradle/gradle#17228).
The workable workaround is to use ${project_name}-build-logic or build-logic-${project_name} naming.