Consider Changing Gradle Default to Kotlin

[rwinch]

With the publication of Kotlin DSL is Now the Default for New Gradle Builds it would be good to consider changing the default Gradle setting to use the Kotlin DSL

[wilkinsona]

Thanks for the suggestion. This is something that we've been keeping an eye on for a while. As things stand, we'd like to see improvements in the support for Kotlin in Eclipse, or for the Kotlin DSL to be easier to write by hand without IDE assistance, before changing the default. There's some more background in #956.

[jamesward]

Following up with some updates on this... As #956 and @wilkinsona highlight, the primary blockers to switching the default to the Kotlin build scripts are:

1. Property setters to support the declarative style
2. KTS editing support in Eclipse

For 1, that is now available in Gradle with support in IntelliJ (more details). For 2, we've had a Google Summer of Code project going that added KTS editing support through the Buildship plugin. This is still in progress but wanted to check on how I can help validate / setup a change to the Kotlin scripts as the default. For example, should I make a PR to the initializr to use the property setter syntax in KTS build files? Do we need docs for Eclipse KTS editing on the Spring side? Other things? Thanks!

[sdeleuze]

Thanks for the property assignment improvement, that allows much more idiomatic build files.

For Eclipse support, I am not myself an Eclipse user, but maybe let us know when that's released and we can reach the members of the Spring team using Eclipse for feedback?

[jamesward]

The Eclipse KTS Support has been released: https://discuss.gradle.org/t/buildship-3-1-8-is-now-available/47036

Let me know if there are any remaining issues with switching the default to KTS. Note that IntelliJ, Gradle, and Android now all have KTS as their default.

[sbrannen]

The Eclipse KTS Support has been released: discuss.gradle.org/t/buildship-3-1-8-is-now-available/47036

The release notes state that there is only "incubating" support and specifically:

The new features are not yet production-ready and it currently does not work on Windows.

So it's not ready for prime time yet.

[jamesward]

Can you have some of your Eclipse users try it and see if it is better than the Groovy support? And if not, that will establish the necessary gaps to fill.

[mhalbritter]

Instead of fiddling with our defaults (which is most of the time a personal opinion), we're going to remember the last choice the user made. That's something the IDE clients do, too. I've opened #1403 for that.

[jamesward]

Defaults (for users who don't know which to pick) are important and it still would be great to align the default on start.spring.io with the same defaults Gradle, Google, and JetBrains use.