The current docs mix the plugins DSL and legacy plugin application:

https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/

Per the Gradle docs: https://docs.gradle.org/current/userguide/plugins.html#sec:old_plugin_application

With the introduction of the plugins DSL, users should have little reason to use the legacy method of applying plugins. (...)

I think the Spring Boot Gradle Plugin docs should use the plugins DSL consistently since that is the recommended approach from Gradle (my understanding).

So, instead of:

apply plugin: 'java'
apply plugin: 'io.spring.dependency-management'

Do:

plugins {
    java
    id("org.springframework.boot") version "3.0.2"
        id("io.spring.dependency-management") version "1.1.0"
}

The plugins DSL is also what is used when generating a project using Spring Initializr.

Comment From: wilkinsona

I'm not sure that we should do this across the board. One disadvantage is that a version number for the dependency management plugin needs to be declared when using the plugins DSL. We mention this in the docs at the moment:

We can make the code less awkward by applying the plugin from the root parent project, or by using the plugins block as we’re doing for the Spring Boot plugin. A downside of this method is that it forces us to specify the version of the dependency management plugin

There are a few areas in the docs where we could use the plugins DSL (applying the java plugin is one) but it's not clear to me that using it exclusively is the right thing to do.

Comment From: ciscoo

I would say it is more explicit/verbose than a disadvantage. I suppose the disadvantage here is that the version of the plugin Spring Boot supports may or may not align with the version of the Dependency Management plugin specified by the user.

But since the Spring Boot plugin declares a dependency on the Dependency Management plugin, then the version Spring Boot provides can override the users version since standard Gradle dependency resolution applies; assuming Spring Boot provides a more recent version than what the user specifies.

For example, the following illustrates the above:

plugins {
    java
    id("org.springframework.boot") version "3.0.2"
    id("io.spring.dependency-management") version "1.0.9.RELEASE"
}

./gradlew buildEnvironment


> Task :buildEnvironment

------------------------------------------------------------
Root project 'example'
------------------------------------------------------------

classpath
+--- org.springframework.boot:org.springframework.boot.gradle.plugin:3.0.2
|    --- trimmed for brevity
\--- io.spring.dependency-management:io.spring.dependency-management.gradle.plugin:1.0.9.RELEASE
     \--- io.spring.gradle:dependency-management-plugin:1.0.9.RELEASE -> 1.1.0

(c) - dependency constraint
(*) - dependencies omitted (listed previously)

A web-based, searchable dependency report is available by adding the --scan option.

BUILD SUCCESSFUL in 506ms
1 actionable task: 1 executed

Additionally, I am wondering if the Spring Boot plugin really needs to declare a dependency on the Dependency Management plugin anyways since the Spring Boot plugin does not depend on it as part of its public API, but rather reacts to its application when applied. Then the disadvantage is more or less moot since you can invoke bootJar without any issues:

buildscript {
    configurations.configureEach {
        exclude(group = "io.spring.dependency-management", module = "io.spring.dependency-management.gradle.plugin")
    }
}

plugins {
    java
    id("org.springframework.boot") version "3.0.2"
}

Finally, there is this part (bottom) in the Gradle documentation Minimizing the use of external libraries:

A future version of Gradle will introduce proper classpath isolation for plugins.

Theoretically (my understanding), the dependency on Dependency Management would no longer 'leak' onto the build environment therefore forcing the user to define a version anyways.

Comment From: wilkinsona

Closed by 81882ecca4f5c1ccba1a1893deb3b026f60e4861.