Linked to #331, I think it could make sense to support Gradle builds written in Kotlin instead of Groovy.
I am experimenting on that for a few month, and it works pretty well, see for example mixit or spring-boot-kotlin-demo build.gradle.kts. As a bonus, that would be nice to make that the default for Kotlin project.
This feature is also valuable for Java projects since it provides full autocomplete and validation of Gradle builds unlike the Groovy variant.
This feature works with regular IntelliJ IDEA Kotlin plugin, but you need to use Kotlin 1.1 EAP plugin to get autocomplete and validation of your build file.
I plan to contribute this feature, that IMO makes sense as part of the Kotlin support provided by Spring Framework 5 (so a good fit with Spring Boot 2.0).
This comes with several challenges. Right now, the UI (and the metadata) offers a "Maven-based" or "Gradle-based" project/build. The introduction of Kotlin makes it a "flavor" of a build type for which we have no concept right now. I am not keen to introduce one.
Also, this would be really weird to offer a way to build a Kotlin-based build with Groovy and a Groovy-based build with Kotlin.
As things stand, I'd be in favor of waiting for it to become a bit more mainstream and use it when a Kotlin project type is created. We might do the same thing for Java type, probably later.
Any other opinion?
Can we automatically generate a Kotlin-powered build.gradle.kts when the users selects Gradle as the build system and Kotlin as the language? That way we'd avoid another UI option at least.
Looks like I did a terrible job at phrasing my proposal. That's exactly what I meant.
Sure we could, but I tend to think it would be better to be explicit. From both user and Initilizr POV, Gradle Groovy and Gradle Kotlin are 2 distinct build systems.
Gradle Kotlin will be IMO quickly asked by Java users given the huge gain in term of autocomplete and validation. On the other way, some people creating Kotlin projects will still want to use Gradle Groovy flavor because for example it is the only thing supported in there company or they want to keep using something stable they know for a very long time.
The combo box allowing selecting the build system contain only 2 items (Maven and Gradle), so I would be for simply adding a Gradle Script Kotlin line, and eventually hide this line in the UI when Groovy and Java languages are selected. When we will consider this mature enough, we will be able to unlock Gradle Script Kotlin for Java projects.
Gradle Script Kotlin
Please, do not forget that Initiliazr has many clients and we should offer whatever customization we support to all of them. That idea of hiding stuff in the web ui is a big no no. This isn't just a line in a combo box, there is a meta-data element behind it. You need to convey that to remote clients as well.
Frankly, I'd be up to generate a Kotlin-based build with Kotlin only and see how folks react to that.
I will follow your recommandation, and I understand that you don't want to introduce some UI tricks, but doing another trick to generate a special Gradle Script Kotlin based build when Kotlin is the selected language seems to be the wrong path to me. How will we do when Java users will require such support? What will be our answer to users using Kotlin language but regular Gradle Groovy based build?
To me Gradle Script Kotlin (btw this name is likely to change before GA) is really another build system, and unlike in Maven World where polyglot Maven seems to stay niche, Gradle clearly said Gradle Script Kotlin is their long term default solution whatever language your use. So since Initializr supports already 2 ones, I still think we should add this as a 3rd regular one.
My hiding stuff proposal was more to provide an answer to your concern about Groovy language projects that don't want to see Gradle Script Kotlin as a build system. But IMO these are orthogonal concerns, I would just list the 3 build systems whatever language you choose, even if for sure Groovy langage project will likely to use more often regular Gradle Groovy builds and if Kotlin projects are more likely to use Gradle Script Kotlin.
Optionally, I could also contribute as a distinct issue/PR a feature that allows to specify in the metadata what is the default build tool for a specific language. In term of UI, we could select by default Groovy Gradle for Groovy project and Gradle Script Kotlin for Kotlin projects. In term of REST API that would enable to generate a project without specifying the build system in the request with the most popular one by default.
Found my way here from some of the Kotlin blog posts.
Adding in Gradle Script Kotlin as a third build option seems like the simplest approach to me.
No changes to the web UI required, and it shouldn't require any updates to the intellij initializr screen either (which is where I normally use it).
I also want to say that I'm against automatically generating a Gradle Script Kotlin build file if Kotlin is selected as the language. That could potentially be pretty jarring/confusing for someone who knows gradle and is using initializr to get started with kotlin, especially if they weren't already aware that Gradle Script Kotlin exists.
Some more brainstorming with @sdeleuze
It looks like the consensus is to let the user chose the format of the build so we need a dedicated concept for it. We've discussed the possibility to have a third element in the first combo ("Generate a") with "Gradle" and "Gradle Kotlin" or something but I am really not a fan of the idea.
We still need to figure out how that would work UI wise for us but a third combo that lists the available format seems to be one way out. For Maven that would be XML and Gradle could have Groovy and Kotlin as options.
Metadata wise, we need a "format" concept with a label and links in each "type". Each type would also define a default "format".
The CLI can be upgraded to understand this new format, something like:
To create a web/data-jpa gradle Kotlin-based project unpacked:
$ spring init -d=web,jpa --build=gradle --format=kotlin my-dir
IDEs that do not support the concept would just provide the usual parameters and the default format would apply for them. New versions could offer a selection for the available format and pass that along the request. Regardless, this change must be fully backward compatible with existing clients.
@bclozel @wilkinsona @dsyer (and anyone else watching here) thoughts?
Adding a format option feels overly complicated to me, particularly as it would only be applicable to Gradle (unless we're going to support polyglot Maven too). My vote would be for a third build option. Sorry, @snicoll