Overview
Kobalt is a build system heavily inspired from Gradle and entirely written in Kotlin. It's focused on offering an intuitive DSL and plug-in architecture, fast builds and build file auto completion from your favorite IDE.
Design goals
- Completely written in Kotlin: core, plug-ins and build files.
- uto completion from the IDE (possibly enhanced by a soon-to-come thin Kobalt IDE plug-in to present suggestions ordered more sensibly).
- Reusing all the good ideas from Gradle, such as the DSL and the wrapper.
- Fast builds.
- Streamlining the build file, applying default over configuration as much as possible (for example, to install a plug-in, Gradle forces you to both declare it and apply it, something I've never understood).
- A turnkey solution with all the common plug-ins pre-installed. No need to go hunting through dozens of outdated results for the elusive JCenter plug-in: with Kobalt, you can create a package and upload it to JCenter within ten minutes.
- An agnostic build tool. Kobalt can be used to build Kotlin and Java projects today but it's capable to build anything: any language (JVM or not) or platform (Android, Spring, ...).
Why Kobalt?
As of this writing (September 2015), Kobalt is in alpha and changing a lot so I am mostly interested in getting the attention of developers who are interested in
- helping with Kobalt's core
- writing plug-ins or extending existing ones
- discussing the architecture and the design of Kobalt on the mailing-list
Kobalt is complete enough to build three of my personal projects (TestNG, JCommander and, of course, itself) but it will most likely come short of filling everyone's build needs at this time. That's the end goal but we're not there yet. You are welcome to use it on your own projects as long as you're okay with encountering issues and reporting them.
With this disclaimer, why did I decide to write Kobalt?
1. Scratching an itch
I give a lot of credit to Gradle for having open a brand new avenue in build tools but despite all its power and flexibility and the fact that I've used Gradle for more than five years, I've never really felt comfortable or fluent with it. Even today, I regularly find myself spending a lot of time on StackOverflow whenever I need to do something a bit out of the ordinary with my Gradle builds.
I suspect a part of it is due to Groovy which, even though it started gaining some static type features these past years, remains at its heart a dynamically typed language. This has two consequences:
- You don't receive a lot of assistance from your IDE when writing Gradle build files (auto completion broken most of the time).
- Building is slow and hard to diagnose because of Gradle's mixed Java/Groovy code base.
2. An experiment
I wanted to see for myself if my discomfort with Gradle was justified or if, by trying to write a build tool myself, I would end up with a very similar tool with similar strengths and weaknesses. I still haven't made up my mind about this but I will certainly by the time Kobalt reaches 1.0.
3. A proof of concept
I have been a fervent believer that there is nothing that dynamically typed languages can do today that statically typed languages can't. Groovy's meta model and features have enabled a lot of clever tricks (DSL and others) for Gradle builds and I was really curious if I could put money where my mouth is by creating a similar project with Kotlin. This experiment is still ongoing but by now, I'm pretty convinced that the answer is a resounding "yes".
4. An excuse to write Kotlin
Just a personal thing. After toying with the language for almost four years now, I wanted to take my efforts to the next level and push the language to the limit. So far, the language has held all its promises and then some.