Skip to content

Latest commit

 

History

History
61 lines (46 loc) · 3.78 KB

README.md

File metadata and controls

61 lines (46 loc) · 3.78 KB
Raw

Good News: I made a simplified version of this template, check it out

modern-gradle-template

I learn Gradle because I want a simplified syntax to describe a multi-module project, so I payed and learned from Udemy

But I end up with this crazy setup that is 10x more complicated than my current maven multi-module project setup 😂

Definitely overkilled for small, personal, or school projects...

How crazy 😲 is this template

See how I structured my precompiled script plugins

image

Also, each module is an independent submodule in the gradle/plugins build source project, and each module in the same layer will never depend on each other.

This is explicitly designed to boost build performance from gradle parallel execution.

performance boost

I want to use this template

Good News: I made a simplified version of this template, check it out

Thanks for considering my template 🙂, just do the following things, and you are good to go:

  1. Delete these sample submodules begin with sample-, and update the logic of including submodules in the root settings.gradle.kts
  2. Modify the project name rootProject.name in settings.gradle.kts to your own project name.
  3. Globally change the group name poc.cx.glp to your own group name. The group name poc.cx.glp is defined in dev-version-constraints module and is referred in the root plugin and the lib mixin plugin.
  4. Delete everything in mixin plugins folder and convention plugins folder, and delete everything in the version catalog, and delete everything in the constraints block in the dev-version-constraints platform
    • Tips: you can choose to not delete some stuff if you find them useful
  5. Add your own mixin plugins and convention plugins, and don't forget to archive centralized version management by adding your own libraries into the version catalog.
    • Tip 1: if you want to use version catalog in the dependencies block in precompiled script plugins (mixin or convention plugins), put them in the constraints block in the dev-version-constraints platform. Then in precompiled script plugins, declare the library dependency without the version (e.g. implementation("org.springframework.boot:spring-boot-starter")). This works for Maven bom and Gradle platform as well.
    • Tip 2: if you want to use version catalog in the plugins block in precompiled script plugins (mixin or convention plugins), you instead let the build.gradle.kts (is also the one with kotlin-dsl applied) that build the precompiled script plugin applies the version catalog. Then in precompiled script plugins, declare the library dependency without the version ((e.g. id("org.springframework.boot"))

This template also contains two ways for updating library dependencies automatically, either by using renovate bot (recommended as it is the only tool that support Gradle version catalog so far), or running Gradle tasks defined in the root build.gradle.kts