Kotlin DSL should not declare the dependency management plugin

[snicoll]

As of Spring Boot 2, the Spring Boot plugin provides the reference of the dependency management plugin so we should just apply it rather than declaring it with a version.

At the moment, the version is wrong on start.spring.io as the version we declare is for Spring Boot 1.x.

[wilkinsona]

There's a trade-off to be made here. The current approach allows boms to be imported like this:

plugins {
    // …
    id("org.springframework.boot") version "2.1.5.RELEASE"
    id("io.spring.dependency-management") version "1.0.7.RELEASE"
}

dependencyManagement {
    imports {
        mavenBom("example:bom:1.0")
    }
}

If the plugin is applied instead, we lose the need to specify the version but the syntax for importing a bom is more cumbersome:

plugins {
    // …
    id("org.springframework.boot") version "2.1.5.RELEASE"
}

apply(plugin = "io.spring.dependency-management")

the<DependencyManagementExtension>().apply {
    imports {
        mavenBom("example:bom:1.0")
    }
}

[sdeleuze]

I think I understand why the dependency management plugin was just applied (in order to leverage automatically the version bundled with Boot plugin) but with the new plugins syntax the apply(plugin = "io.spring.dependency-management") looks weird from a Gradle user POV, and with Gradle Kotlin DSL it is very important to allow access via the dependencyManagement as pointed out by @wilkinsona, so I would vote for keep using the pluign syntax and fixing the version in a consistent way for both Groovy and Kotlin DSL.

I guess the challenge here is to be able to infer io.spring.dependency-management version from org.springframework.boot, but for Gradle users that would be the best outcome and would be less confusing.

[snicoll]

I am not keen to have to manage the version of the plugin if that can be inferred by the Spring Boot maven plugin. This is double maintenance on our end with a very easy way of using the wrong version.

[sdeleuze]

IMO the ideal solution could be to retrieve version of plugins from Spring Boot artifact metadata, that could be used for dependency management plugin, Kotlin, etc. Not sure exactly yet how to do that (compute a cache with that info during build time?) but that would give users idiomatic Gradle build files with explicit non confusing versions defined and would improve maintenance cost.

[snicoll]

compute a cache with that info during build time?

We can't do that as the version of Spring Boot changes dynamically according to the info in Sagan.

[sdeleuze]

We can't do that as the version of Spring Boot changes dynamically according to the info in Sagan.

For middle term solution, maybe Initializr could get the info from Sagan and/or Maven central via WebClient and use the awesome caching feature you built to make that fast and reliable?

[snicoll]

So we've decided to keep the declaration as it is. #977 will take care of retrieving the version from the maven metadata as we already do for Kotlin.