Use Gradle "version catalogs" and the TOML file

multi-module/README.md

@@ -6,28 +6,36 @@ This sub-project illustrates a multi-module Gradle project.
 
 Read more about Gradle's support for multi-project builds at the [official doc site](https://docs.gradle.org/current/userguide/kotlin_dsl.html#sec:multi_project_builds).
 
+
 ## Instructions
 
-1. The interesting part of this project is the Gradle configuration. So, read the `build.gradle.kts` files. But still, it's
-   useful to execute the example applications to prove that it works. Follow the below steps to build and run the applications.
-2. Use Java 17
-3. Run `module-a`:
-   * `./gradlew :module-a:run`
-4. Run `module-b`:
-   * `./gradlew :module-b:run`
+The interesting part of this project is the Gradle configuration. So, read the `build.gradle.kts` files. But still, it's
+useful to execute the example applications to prove that it works. Follow the below steps to build and run the programs:
+
+1. Use Java 17
+2. Run `module-a`:
+   * ```shell
+     ./gradlew :module-a:run
+     ```
+3. Run `module-b`:
+   * ```shell
+     ./gradlew :module-b:run
+     ```
+
 
 ## Wish List
 
 General clean-ups, changes and things I wish to implement for this project:
 
-* DONE (update: yes use the "java-platform" plugin) Is it possible to define a Maven BOM in the root project and consume it from the sub-projects? The effect of this is
+* [x] DONE (update: yes use the "java-platform" plugin) Is it possible to define a Maven BOM in the root project and consume it from the sub-projects? The effect of this is
   that the sub-projects should not have to declare the dependency versions and the versions defined by the BOM should be
   used. I have the "consuming-a-maven-bom" sub-project, but in this case we want to *define* our own BOM. Consider creating a
   whole new sub-project but I figure that the "common dependency version declaration" use case is almost universal for
   multi-module projects, and I want "common dependency version declaration" implemented in "multi-module/". I think a BOM
   is how to do it because there is some problem (maybe will be fixed in Gradle 7?) about root project dependency declarations
   being applied to sub-projects even if you don't want them (not good).
-* Recently I'm preferring Gradle ["pre-compiled script plugins"](https://github.com/dgroomes/http-client-server-playground/blob/main/buildSrc/src/main/kotlin/common.gradle.kts)
+* [x] OBSOLETE (I'm using the "version catalog" instead of this approach) Recently I'm preferring Gradle ["pre-compiled script plugins"](https://github.com/dgroomes/http-client-server-playground/blob/main/buildSrc/src/main/kotlin/common.gradle.kts)
   –also called convention scripts– instead of the platform feature via the `java-platform` plugin. Maybe the platform
   feature is best suited when it is published, like the Jackson or JUnit BOMs. But for a given project, I think the
   bespoke versioning constraints are best done in a conventions script. Replace the platform with a conventions script. 
+* [x] DONE Use [Gradle's version catalogs](https://docs.gradle.org/current/userguide/platforms.html#sub:version-catalog)

multi-module/build.gradle.kts

@@ -1,7 +1,6 @@
-val dependencyConstraints = project(":dependency-constraints")
+val versionCatalog = extensions.getByType<VersionCatalogsExtension>().named("libs")
 
-// Configure all of the sub-projects except for the "dependency-constraints" project
-configure(subprojects.minus(dependencyConstraints)) {
+subprojects {
     apply(plugin = "java")
     apply(plugin = "application")
 
@@ -25,9 +24,13 @@ configure(subprojects.minus(dependencyConstraints)) {
         Gradle APIs." So there you have it: cross-configuring is a significant trade-off that might make your
         project's build files more DRY/expressive but limits the ability of the Gradle Kotlin DSL to bring type-safety to
         those very same build files.
+
+        UPDATE 2022-08-28 Continuing the type-unsafe trend... Now I want to use "version catalogs" and the associated
+        TOML file. But when I try to use 'libs.slf4j.api' I'm getting the error: 'Extension with name 'libs' does not exist.'
+        I need to use the version catalog with the type-unsafe API described here https://docs.gradle.org/current/userguide/platforms.html#sub:type-unsafe-access-to-catalog
+        Specifically, I need: extensions.getByType<VersionCatalogsExtension>().named("libs")
         */
-        "implementation"(platform(dependencyConstraints))
-        "implementation"("org.slf4j:slf4j-api")
+        "implementation"(versionCatalog.findLibrary("slf4j-api").get())
     }
 }
 
@@ -50,6 +53,6 @@ val moduleB = project(":module-b")
  */
 configure(listOf(moduleA, moduleB)) {
     dependencies {
-        "implementation"("org.slf4j:slf4j-simple")
+        "implementation"(versionCatalog.findLibrary("slf4j-simple").get())
     }
 }

multi-module/gradle/libs.versions.toml

@@ -0,0 +1,7 @@
+[versions]
+# SLF4J releases: http://www.slf4j.org/news.html
+slf4j = "1.7.36"
+
+[libraries]
+slf4j-api = { module = "org.slf4j:slf4j-api", version.ref = "slf4j" }
+slf4j-simple = { module = "org.slf4j:slf4j-simple", version.ref = "slf4j" }

multi-module/settings.gradle.kts

@@ -1,6 +1,5 @@
 rootProject.name = "multi-module"
 
 include(
-        "dependency-constraints",
         "module-a",
         "module-b")