Back at JavaOne 2015, during a lunch break we started chatting with Hans Dockter, CEO of Gradle. A couple of days after the conference, a few of us were at the Gradle offices talking about what would be the beginning of the collaboration between JetBrains and Gradle; to bring first-class tooling and support for a static language to Gradle.
Today, at the Kotlin Night in San Francisco, Hans Dockter demoed the first milestone of writing a Gradle build script using Kotlin.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
import org.gradle.api.plugins.* import org.gradle.api.tasks.wrapper.* import org.gradle.script.lang.kotlin.* apply<ApplicationPlugin>() configure<ApplicationPluginConvention> { mainClassName = "samples.HelloWorld" } repositories { jcenter() } dependencies { "testCompile"("junit:junit:4.12") } |
Gradle allows developers and build engineers to deal with complex build automation scripts. As complexity grows, having a language that is statically-typed can help detect potential misconfigurations at compile time, contributing in reducing runtime issues. Static typing also opens up the door to more sophisticated tooling. All this, combined with key characteristics of Kotlin that enable easy creation of DSL’s, can provide Gradle users benefits while maintaining the level of fluency they are accustomed to.
For the past 6 months, we’ve been working closely with the Gradle team, in particular with Chris Beams and Rodrigo de Oliveira in bringing Kotlin to Gradle. It has been a tremendously rewarding experience because it has also helped us see use-case scenarios for making scripting in Kotlin a first-class citizen.
We are very excited for what Gradle has in store and are happy to continue collaborating with them closely in bringing a great experience to Gradle users.
For more information and how to get the bits to start playing with this, make sure you read the blog post by the Gradle team for more details. In addition, if you are on the public Kotlin Slack, there’s a newly created #gradle channel for discussions.
Although I understand why,
is not:
or similar (sorry, I don’t know much of Kotlin) and is prone to typing error.
I believe at that point, there’s no knowledge of samples.HellowWorld.class
mainClassNameis from the existing GradleApplicationPlugin, which is applied at the top. The equivalent existing Gradle script would be:The key is that
mainClassNameis not actually used by the application plugin to do anything except write the name to the jar so that the jar can be used without supplying a class name (e.g.,java -jar myjar.jar).Great news! It might be interesting to see which of Gradle and Kobalt (http://beust.com/kobalt/home/index.html) will make better use of Kotlin.
Well, the significant upshot is that Gradle doesn’t involve that Beust person, so the environment is a bit better.
He is very friendly and responsive, actually
I’m surprised that Gradle team hasn’t explored using @CompileStatic/@TypeChecked, @DelegatesTo and @ClosureParameters to support auto-completion and compile-time checking. I’ve built similar DSLs with these to support auto-complete and checking in IntelliJ. How does the Kotlin-based solution compared to what you can do with modern Groovy?
Jason,
Unfortunately this is something that is best asked to Gradle, not us.
Well my question was about comparing a solution using static compilation of Groovy with Kotlin. But since posting I’ve learned there has been work on Groovy towards supporting static compilation of Gradle scripts, meaning Groovy’s support is not sufficient. So that is the answer to my question: while Groovy has static compilation mode it is not sufficient to address everything that Gradle can do, so Kotlin has better support for static DSLs like we see here and that makes it a compelling case for Gradle.
That’s not the case. The experiment shows that it can do what we want. The problem we have now is IDE support (IDEA, Eclipse).
Good luck! This unfriendly to humanity build system needs some fresh air.
Pingback: Issue #206-IT资讯
Awesome! I’m in the process of porting a 15-year-old Ant build to Gradle, and the most frustrating part is the lack of in-IDE documentation. As in: “Where is this coming from?” “What can I put there?” “How does this block really work?”
Just having the imports in the build file is a real help.
Pingback: Diario di Grails (settimana 20 del 2016) | BME