This PR introduces Java 17 support for Telestion and cleans up the configuration for the build pipeline.
Details
Due to many deprecations in the Gradle API and the somewhat spooky build configuration of Telestion Core I took a deep-dive into Gradle and multi-project configuration with shared build configurations.
I tried to be as convention-complete to the Gradle docs as possible. Maybe I missed some parts, so be sure to check out the changes I made and mark parts that are missing or incomplete.
To the new configuration approach:
Plugin-based configuration
The Gradle docs say that allprojects and subprojects closures no longer recommended because of the increased configuration time and the weird configuration logic. So I introduced two Gradle plugins that abstract the build logic for a Telestion Core Java Project (plugin named telestion-java) and a Telestion Core Java Library Project (plugin named telestion-java-library) and an extension to configure these plugins. (An extension is like a data storage that is defined in the project and passed into the plugin during configuration)
These plugins are defined in the new buildSrc folder. This folder has a somewhat special meaning in Gradle terms as it's designed to hold plugins for the project. The plugin definitions inside this folder look like the Gradle DSL for the project configurations and that is the trick of this special folder.
These plugins are then applied to every subproject in Telestion Core (e.g. telestion-api, telestion-services, ...) and thus reduce the duplicate configuration and maintenance overhead.
The way to Kotlin
During the creation of this tasks I had a real headache with the dynamic/weak typing of Groovy and decided to switch to Kotlin as configuration language. (same reason as above: better maintenance :stuck_out_tongue_winking_eye:)
Dependency catalog
Gradle provides a relatively new feature to merge the definition of same dependencies in different project into one declaration spot. This feature is called dependency catalog and the new catalog for Telestion Core resides in gradle/libs.versions.toml.
Simply said, you give a dependency an alias and use this alias throughout the project. So you have only one dependency with the same version installed.
With a view to our new dependency updater renovate this is useful because the updater supports this kind of dependency definition.
Regressions
I removed the allJavadoc task that combined the generated Javadoc from all project into one big Javadoc webpage because we currently don't use any of the generated Javadoc and link instead to the Javadoc reader https://javadoc.io/. If we decide to include this task again, we need to take a look into the Gradle API because some features in Groovy are not compatible with Java or Kotlin.
Additional information
Short and spicy changelog:
update to Gradle v7.6
declare all dependencies in gradle/libs.versions.toml
add buildSrc
add telestion-java plugin to configure java-based projects
add telestion-java-library plugin to configure java-library projects
add extension to configure the pretty name and description of the project
move the entire build, test and deploy pipeline into these plugins
move all subprojects out of the :module subproject
rewrite all project configurations to use the new plugins
switch to Kotlin as configuration language
removed the alljavadoc task
CLA
[x] I have signed the individual contributor's license agreement and sent it to the board of the WüSpace e. V. organization.
Note
As always, if no one complains I see the PR implicitly accepted after 2 weeks. :wink:
Summary
This PR introduces Java 17 support for Telestion and cleans up the configuration for the build pipeline.
Details
Due to many deprecations in the Gradle API and the somewhat spooky build configuration of Telestion Core I took a deep-dive into Gradle and multi-project configuration with shared build configurations. I tried to be as convention-complete to the Gradle docs as possible. Maybe I missed some parts, so be sure to check out the changes I made and mark parts that are missing or incomplete. To the new configuration approach:
Plugin-based configuration
The Gradle docs say that
allprojectsandsubprojectsclosures no longer recommended because of the increased configuration time and the weird configuration logic. So I introduced two Gradle plugins that abstract the build logic for a Telestion Core Java Project (plugin namedtelestion-java) and a Telestion Core Java Library Project (plugin namedtelestion-java-library) and an extension to configure these plugins. (An extension is like a data storage that is defined in the project and passed into the plugin during configuration) These plugins are defined in the newbuildSrcfolder. This folder has a somewhat special meaning in Gradle terms as it's designed to hold plugins for the project. The plugin definitions inside this folder look like the Gradle DSL for the project configurations and that is the trick of this special folder. These plugins are then applied to every subproject in Telestion Core (e.g.telestion-api,telestion-services, ...) and thus reduce the duplicate configuration and maintenance overhead.The way to Kotlin
During the creation of this tasks I had a real headache with the dynamic/weak typing of Groovy and decided to switch to Kotlin as configuration language. (same reason as above: better maintenance :stuck_out_tongue_winking_eye:)
Dependency catalog
Gradle provides a relatively new feature to merge the definition of same dependencies in different project into one declaration spot. This feature is called dependency catalog and the new catalog for Telestion Core resides in
gradle/libs.versions.toml. Simply said, you give a dependency an alias and use this alias throughout the project. So you have only one dependency with the same version installed. With a view to our new dependency updater renovate this is useful because the updater supports this kind of dependency definition.Regressions
I removed the
allJavadoctask that combined the generated Javadoc from all project into one big Javadoc webpage because we currently don't use any of the generated Javadoc and link instead to the Javadoc reader https://javadoc.io/. If we decide to include this task again, we need to take a look into the Gradle API because some features in Groovy are not compatible with Java or Kotlin.Additional information
Short and spicy changelog:
gradle/libs.versions.tomlbuildSrctelestion-javaplugin to configure java-based projectstelestion-java-libraryplugin to configure java-library projects:modulesubprojectalljavadoctaskCLA
Note
As always, if no one complains I see the PR implicitly accepted after 2 weeks. :wink: