The Gradle Kotlin DSL is now documented

More than 2 years ago, I wrote

Kotlin has also been announced as the future language of choice for Gradle, and I can’t wait to be able to use it for my Gradle builds.

It turns out I had to wait quite a bit. Using the Gradle Kotlin DSL is possible for some time now, but it was a bit of a frustrating experience due to the lack of documentation, to the point that I wrote a migration guide a few months ago.

As promised by the Gradle team, a much better, more complete, official migration guide now exists.

The huge, fantastic Gradle user guide, however, still only shows Groovy samples. But not for long. I’ve spent some time, along with other folks, translating all the samples of the user guide from Groovy to Kotlin. The result is already available in the Gradle nightly.

So you have no excuse anymore. Try the Kotlin DSL. It works, it is quite close to the Groovy DSL, but with less black magic involved, and it does allow auto-completion and navigation to the sources in IntelliJ.

Translating the samples has been a great experience. And it helped finding and fixing a few issues, too. Contributing to an open-source project you like and respect is always gratifying. You get the feeling that what you’re doing matters. Gradle folks have been nothing but kind, understanding, helpful, grateful… and demanding.

I didn’t just decide to contribute though. That’s always intimidating: where to start? How to get help? Will I help, or will I be a burden for the maintainers?

I contributed because the Gradle team asked me to. First after I wrote my migration guide, and after when they opened this epic issue, asking for help from contributors, and providing detailed instructions and examples on how to accomplish the task.

I wish more big open-source projects do that. Tagging issues with “ideal-for-contribution” is also nice. What might seem like grunt work for project maintainers or experienced contributors is an interesting challenge and learning experience for casual, less-experienced developers who are willing to help.

So, if you’re an open-source project maintainer and you read this, please make it easy to start contributing on your project. Ask for help. And communicate on public channels (blogs, tweets, etc.) about it. I’m apparently not the only one to have this opinion, so here is some more food for thoughts.