What is Kobalt?

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.

For example, here is JCommander's entire build file:

import com.beust.kobalt.*
import com.beust.kobalt.plugin.java.*
import com.beust.kobalt.plugin.packaging.*
import com.beust.kobalt.plugin.publish.*

val jcommander = javaProject {
    name = "jcommander"
    group = "com.beust"
    artifactId = name
    version = "1.52"

    dependenciesTest {
        compile("org.testng:testng:6.9.5")
    }

    assemble {
        mavenJars {
        }
    }

    jcenter {
        publish = false
    }
}

Design goals

• Completely written in Kotlin: core, plug-ins and build files.
• Auto 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.
• Support all scopes (including provided).
• Streamlining the build file, applying "convention over configuration" as much as possible (for example, to install a plug-in, Gradle forces you to both declare it and apply it. With Kobalt, the simple act of declaring a dependency on it installs the plug-in).
• A turnkey solution with all the common plug-ins pre-installed. With Kobalt, you can create a package and upload it to JCenter within ten minutes. See for yourself!
• 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 (October 2015), Kobalt is in alpha and changing a lot so I am mostly interested in getting the attention of developers who are curious about:

• 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.

The path to Kobalt 1.0

Even though Kobalt is currently in Alpha, I'm already using it to build most of my projects. Here are links to a few build files you can inspect to get a feel for what Kobalt enables:

• JCommander.
• TestNG (this build file shows an example of adding a custom task in the build itself).
• ... and of course, Kobalt itself (this build file demonstrates multi projects and project dependencies).

Here are some of the features I'm either working on or planning to (or hoping that a contributor will take on):

• More plug-ins: Android, web, apt, coverage, etc...
• Improve existing plug-ins (Java, Kotlin, etc...).
• An IDEA plug-in to improve auto completion in the IDE. Since Kobalt build files are Kotlin files, the IDE already does a good job at offering helpful auto completion suggestions, but a thin plug-in on top of the Kotlin mode would allow to reorder these suggestions and put the Directives (Kobalt's functions that you can use in a build file) at the top of the list, making writing build files even easier than it already is.
• Support for build flavors and build types. I'd like to adapt what's currently available in the Gradle Android plug-in and make it available across all build types (e.g. debug/release, etc...), which might mean supporting build flavors and types in Kobalt's core itself.

Is your curiosity piqued? Are you interested in writing some cool Kotlin code and contribute to Kobalt? Or maybe just download and run Kobalt on your own projects just to get a feel for it? Then proceed to Kobalt's main documentation!