gradle-playground

📚 Learning and exploring the Gradle Build Tool.

From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster. -- https://gradle.org

Why is this useful?

Gradle can be complex to configure correctly because it is a powerful DSL with a rich set of features and plugins. It's hard to remember the exact incantations to write in a build.gradle (or build.gradle.kts for that matter) to configure, for example, the enablement of Java language preview features or JUnit test logging.

While all the information you need to configure a Gradle project is technically available in the highly thorough and accurate official Gradle documentation and embedded in executable sample projects within the Gradle source code repository, this repository contains my own personal examples that I need to refer back to continuously in my day-to-day development. In other words, this repository whittles down the full scale of Gradle to a few files for my own quick reference.

Standalone subprojects

This repository illustrates different concepts, patterns and examples via standalone subprojects. Each subproject is completely independent of the others and do not depend on the root project. This standalone subproject constraint forces the subprojects to be complete and maximizes the reader's chances of successfully running, understanding, and re-using the code.

The subprojects include:

java-preview-features/

Configure Gradle to build and run a project that uses Java Preview Features.

See the README in java-preview-features/.

java-early-access-via-toolchain/

This subproject illustrates how to leverage Gradle's Toolchains for JVM projects to use an early-access version of Java in a Gradle project.

See the README in java-early-access-via-toolchain/.

consuming-a-maven-bom/

Consume a Maven BOM in a Gradle project and strictly override a BOM dependency.

See the README in consuming-a-maven-bom/.

multi-module/

A poorly configured multi-module Gradle project.

See the README in multi-module/.

plugin/

Write and apply a custom Gradle plugin. This project also showcases Gradle's buildSrc feature.

See the README in plugin/.

java-modules/

An example Gradle project that uses the Java Platform Module System (JPMS).

See the README in java-modules/.

Wish List

General clean-ups, changes and things I wish to implement for this project:

• DONE Revive java-toolchain and upgrade it to Java 20 (because Java 18 I can't download easily so I'm going to just unload this subproject from the settings.gradle.kts file for now)
• DONE Updates for 2023.
• DONE Implement a java-preview-features-kotlin-dsl subproject. (Pretty much copy https://github.com/dgroomes/wiremock-playground/blob/db2684af8617995106e7793ea1348e1d6516bc70/build.gradle.kts)
• DONE java-preview-features to java-preview-features-groovy-dsl and java-preview-features-kotlin-dsl to java-preview-features because the Kotlin DSL is now fully usable and featureful in my experience. This was not quite true a year ago but it is really good now! I love the auto-completion.
• DONE Add a multi-module Gradle project example. Similar to the one defined at https://github.com/dgroomes/kafka-playground/blob/557243bea2960a18e5b11da04f2cec46989576ee/build.gradle.kts#L10
• DONE Add a subproject that showcases buildSrc/
• DONE Remove mavenLocal(). Great official explanation in the Gradle docs
• DONE Upgrade to Gradle 6.8.1 (when it comes out)
• DONE Build in GitHub Actions
• Can we get both Java 15 and Java 16 in the GitHub Actions build environment? If we could, then we can include the 'java-toolchain/' subproject to the 'assembleAll' Gradle task.
• Incorporate Gradle's test fixtures feature in one of the subprojects
• DONE (I implemented something in scratch. I couldn't figure out the architecture though. I think it creates a new classloader and loads the jars from the download Gradle distros) Consider exploring Gradle's Tooling API for programmatic access to Gradle. I don't know if I'll ever have a use-case for this, but I won't know until I learn it.
  • This note caught my eye. How does this work?

  • A fundamental characteristic of the Tooling API is that it operates in a version independent way. This means that you can use the same API to work with builds that use different versions of Gradle, including versions that are newer or older than the version of the Tooling API that you are using. The Tooling API is Gradle wrapper aware and, by default, uses the same Gradle version as that used by the wrapper-powered build.