I’ll start a new project to test the kotlin language and I’d like to know what’s the recommended build tool to use with kotlin.
Maven or Gradle? Why?
Thanks!
1 Like
Highly recommend Gradle because of the following:
-
New Kotlin build features appear in Gradle first before Maven
-
A general observation that most Kotlin projects using a build system use Gradle (around 80%?)
-
Kotlin support in Gradle is more mature
-
Gradle Inc use Kotlin to provide a statically typed build DSL (you write it in Kotlin) for Gradle, which is under development
-
Many of the high profile JetBrains projects (written in Kotlin) use Gradle, some are listed below:
-
Plenty of high profile third party Kotlin projects using Gradle, some are listed below:
I’m sure there are plenty of other Kotlin libraries/frameworks using Gradle, take your pick 
. FYI you can find a general list of Kotlin resources here (includes links to various Kotlin libraries/frameworks).
4 Likes
I do not think there is some “recommended” tool. Everyone can decide for themselves according to their needs. In my opinion gradle is much more powerful and modern. It contains most of maven features and additionally allows to do tons of new things.
Also, if you ever want to switch platform to android, js or native, you will have to use gradle anyway since maven is made for java only.
1 Like
I currently use Gradle because I find it simpler to specify the build files with Gradle than Maven.
However I see it as a matter of personal preference and I don’t think that there’s an actual “preferred way”.
Is the project personal, or for company? What else is used in the company, or can you set the standard? How big will the project(s) become? How many modules and sub-projects might there be?
What are you most familiar with? Do you want to learn a new build-tool alongside learning Kotlin?
What IDE do you use, and how well does the build system integrate in your IDE? (NetBeans has best Maven integration of any IDE I’ve seen but worse Gradle integration, for instance).
It’s a company project.
Here we use Scala/Java with maven. But is not a problem add a new tool.
Maybe only one module
I’ll try to use Gradle.
Thanks
If you’re flexible, i’d recommend Kobalt. It’s written in Kotlin and build files make sense
But is it mature?
We have a private Nexus. Will work well with it?
Thanks, I’ll try
The problem with kobalt is that it is acutally kotlin code. The same is its greatest advantage, but it is also greatest defficiency.
The best thing in Maven is that it purely declarative, no imperative parts and therefore no bizarre behaviors. Gradle, allows a imperative and even functional code, but at the core it is still declarative. Kobalt example from their main page looks good, but let’s go to some real example like ktor. And we immediately have an extension function inside the build scrip. It is cool and kotlin, but it is a great problem because readability is dropped by the order of magnitude. Also it is a very good source of potential errors.
I like kotlin very much, but groovy is obviously better for DSL. Also, it is very hard to make something like gradle, but not gradle. Gradle has huge community and commercial support. Comparing to it, kobalt will always be a toy for kotlin enthusiasts and some people, who for some reason hate groovy.
2 Likes
Kotlin doesn’t have package visibility, so you should evaluate multi module project
If you are a maven expert or a gradle expert, use those. If not, and you don’t want to have to learn the mysterious workings of those tools (what allows them to be so declarative), then Kobalt is easy to learn and to read.
Because it is plain Kotlin, you can do whatever you need to do. I don’t see what is wrong with an extension function. Kotlin extension functions in yoir build won’t affect anything outside your build, unless you don’t really know Kotlin.
Well, that’s relative. I’ve been using it for two years in production. If you don’t upgrade it, it will always work the same. There was a time where upgrades were painful. But things have been quite stable for months.
I am an android developer so now i just Gradle to build with kotlin it’s better with android studio.
As for using Kobalt, because it’s in Kotlin, I belive that Gradle supports using Kotlin instead of Groovy to write its build scripts:
That is true, gradle does have a kotlin version. It reads much like the groovy except you get some IDE support (not as good as with kobalt build files).
Still, for someone like me, who is not a gradle expert, Kibalt is much easier to understand. I don’t have to study my build tool as much and the build files resemble the regular, imperative/functional/OO code that i’m paid to write all day.
A bit strange logic. Kobalt design was copied from Gradle. Gradle code is also valid groovy code (which is very similar to kotlin but for dynamic typing). The only exception is the task construct which could not be reproduced by language features and instead is produced by AST. It greatly improves readability, so no complaints here. By the way introducing new tasks in Kobalt looks like a headache.
Steel, I agree that build system for personal use is a question of preference. Some people do like makefiles. The large project development is another thing completely.
Adding a task in Kobalt is trivial.
The differences between kobalt and gradle build files are subtle but important. I find Kobalt much less magical and much more consistent.
Clearly, most people are happy with Gradle and also hibernate and things like that
There is also Bazel which is by Google and in beta.
There are Kotlin rules that can be used: GitHub - pubref/rules_kotlin: Bazel rules for Kotlin
I am using it with some of my hobby projects and find it usable.
My biggest pain comes from the lack of Bazel integrating in my IDE (IntelliJ).
With Google adopting Kotlin for Android, maybe we can expect more interest in getting Bazel and Kotlin working together. I sure hope so
Extremely unlikely that Google will add official Kotlin support in Bazel. Google are committed to using Gradle as the official build system for Android development. Gradle is likely to become even more entrenched once Google get involved with Gradle Kotlin DSL.
Now with that said stranger things have happened. Google have recently added support for Kotlin on Google App Engine (serverside). That could change the Bazel situation (BIG IF!). Are there any areas where Bazel is widely used (Android doesn’t count)?
1 Like
Gradle does also support “Gradle Kotlin DSL” and even seems to say this is the future for Gradle. The statement that “but groovy is obviously better for DSL” ( @darksnake ) is at least debatable, given that the people behind Gradle seem to now prefer Kotlin, although this is stiall a work in progress.
However, all gradle documentation is for Gradle Groovy DSL, and the documentation for Gradle Kotlin DSL, currently assumes the reader already is familiar with Gradle Groovy DSL.
At this time, if you don;t already know Gradle, you must first learn Gradle Groovy DSL, and then you can transfer to Gradle Kotlin DSL. Groovy is only needed to get started, so this is very frustrating if you do not already know Gradle before learning Kotlin.
In the same manner most Kotlin documentation assumes you know Java. So if you hire team members and wish to train them in Kotlin, the must first learn Java even though they will not program in Java.
This is all a transition problem, and will go away with time, but is frustrating for people coming to Kotlin who have not recently been in the Java/Gradle world.
This opens a window for ‘kobalt’: people adopting Kotlin but not from the Java/Gradle world. Kobalt promises the use of kotlin rather than groovy right now, and no need to learn a language (groovy) just to be able to read the documentation of Gradle Kotlin script!.
So @jpliska, I will take your advise and try kobalt, and if it goes well introduce it to our project teams.
To make Gradle adoption easier, I’ve written an official Building Kotlin JVM Libraries guide for Gradle — hope you enjoy!
Regarding Gradle docs in Groovy: we’re hard at work on better docs and samples. Stay tuned.
2 Likes