https://github.com/dgroomes/gradle-playground
📚 Learning and exploring Gradle (the Java build tool)
https://github.com/dgroomes/gradle-playground
gradle java java-records java14
Last synced: 14 days ago
JSON representation
📚 Learning and exploring Gradle (the Java build tool)
- Host: GitHub
- URL: https://github.com/dgroomes/gradle-playground
- Owner: dgroomes
- Created: 2020-03-16T05:10:34.000Z (about 6 years ago)
- Default Branch: main
- Last Pushed: 2026-04-25T22:26:33.000Z (about 1 month ago)
- Last Synced: 2026-04-26T00:32:55.658Z (about 1 month ago)
- Topics: gradle, java, java-records, java14
- Language: Java
- Homepage:
- Size: 411 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# gradle-playground
📚 Learning and exploring the Gradle Build Tool.
> Gradle is the open source build system of choice for Java, Android, and Kotlin developers. From mobile apps to microservices, from small startups to big enterprises, it helps teams 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.kts` 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](https://docs.gradle.org/current/userguide/userguide.html) and embedded in
[executable sample projects within the Gradle source code repository](https://github.com/gradle/gradle/tree/master/platforms/documentation/docs/src/snippets),
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_](https://openjdk.java.net/jeps/12).
See the README in [java-preview-features/](java-preview-features/).
### `java-early-access-via-toolchain/`
This subproject illustrates how to leverage Gradle's [Toolchains for JVM projects](https://docs.gradle.org/current/userguide/toolchains.html)
to use an early-access version of Java in a Gradle project.
See the README in [java-early-access-via-toolchain/](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/](consuming-a-maven-bom/).
### `pre-compiled-script-plugin/`
Using a *pre-compiled script plugin* to apply common conventions to Gradle subprojects.
See the README in [pre-compiled-script-plugin/](pre-compiled-script-plugin/).
### `multi-project-cross-configuration/`
A multi-project Gradle build configured with cross-project configuration using the `allprojects` and `subprojects` DSL constructs.
See the README in [multi-project-cross-configuration/](multi-project-cross-configuration/).
### `plugin/`
Write and apply a custom Gradle plugin. This project also showcases [Gradle's `buildSrc` feature](https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:build_sources).
See the README in [plugin/](plugin/).
### `java-modules/`
An example Gradle project that uses the Java Platform Module System (JPMS).
See the README in [java-modules/](java-modules/).
## Wish List
General clean-ups, changes and things I wish to implement for this project:
* [x] 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)
* [x] DONE Updates for 2023.
* [x] DONE Implement a `java-preview-features-kotlin-dsl` subproject. (Pretty much copy )
* [x] 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.
* [x] DONE Add a multi-module Gradle project example. Similar to the one defined at
* [x] DONE Add a subproject that showcases `buildSrc/`
* [x] DONE Remove `mavenLocal()`. Great official explanation in the [Gradle docs](https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:case-for-maven-local)
* [x] DONE Upgrade to Gradle 6.8.1 (when it comes out)
* [x] 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](https://docs.gradle.org/current/userguide/java_testing.html#sec:java_test_fixtures)
feature in one of the subprojects
* [x] 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](https://docs.gradle.org/current/userguide/third_party_integration.html#embedding) 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.
* [x] DONE `pre-compiled-script-plugin` subproject
* I use pre-compiled script plugins somewhat often. They are a natural thing to reach for in a multi-module Gradle project. I find myself wanting them as soon as I have to repeat the junit/testing config stanza more than twice. That said, they aren't perfect, especially because of some restrictions that make the ergonomics worse, when paired with version catalogs. See [Gradle GH issue #15383: *Make generated type-safe version catalogs accessors accessible from precompiled script plugins*](https://github.com/gradle/gradle/issues/15383#issuecomment-779893192). That leads you to using a work-around that escalates the complexity to a point where I have a hard time recommending the pattern for a typical team of software engineers. I have gone back and forth on this so many times. I need to at least lock in an example, complete with generous links and explanation and a characterization of the trade-offs.