From 3534d794ac97e58901aa1258373393b9ef75f7bc Mon Sep 17 00:00:00 2001 From: Cedric Beust Date: Thu, 1 Oct 2015 05:18:36 -0700 Subject: [PATCH] Doc. --- index.html | 429 ++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 395 insertions(+), 34 deletions(-) diff --git a/index.html b/index.html index e9bd6aa..4a78572 100644 --- a/index.html +++ b/index.html @@ -39,58 +39,419 @@ Kobalt
-

Page Title

-

A subtitle for your page goes here

+

Kobalt

+

A build tool for the exigent developer

-

How to use this layout

+

Why Kobalt?

- To use this layout, you can just copy paste the HTML, along with the CSS in side-menu.css, and the JavaScript in ui.js. The JS file uses vanilla JavaScript to simply toggle an active class that makes the menu responsive. +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. +
  • 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. +
  • 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, etc...). +
  • The opportunity to have features that I've always missed from Gradle, such as Kobalt's --checkVersions command which will check for you if any of your dependencies have newer versions available. +
+ +

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

-

Now Let's Speak Some Latin

-

- Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. -

+

Documentation

+ +

Downloading and installing Kobalt

+ +Download the zip file (bottom left of the screen) then unzip it in a location we'll call KOBALT_HOME: + +
+cd $KOBALT_HOME
+unzip kobalt-xxx.zip
+
+ +Change to your project directory and call the kobaltw command with --init: + +
+cd ~/java/project
+$KOBALT_HOME/kobaltw --init
+
+ +This command will do two things: + +
    +
  1. Create a default Build.kt file in your current directory based on what was found there. +
  2. Install the Kobalt Wrapper in your current directory (script `kobaltw`) and in the kobalt/ directory. From now on, you can just use ./kobaltw to build and you can ignore $KOBALT_HOME. +
+ +You can now attempt to build your project with Kobalt: + +
+./kobaltw assemble
+
+ +If your project follows a regular build structure (e.g. Maven's hierarchy), this should compile your file and create a .jar file. If not, you will have to make a few edits to your Build.kt. + +As of this writing, Kobalt supports Java and Kotlin projects. + +

Structure of a build file

+ +

General concepts

+ +The build file is typically called Built.kt and it is a valid Kotlin file. Typically, it contains imports, the declaration of one or more projects and the declaration of additional configurations (e.g. packaging, publishing, etc...). Since it's a Kotlin file, it can also contain any class or function you need: + +
+import com.beust.kobalt.*
+import com.beust.kobalt.plugin.kotlin.kotlinProject
+
+val kobalt = kotlinProject {
+    name = "kobalt"
+    group = "com.beust"
+    artifactId = name
+    version = "0.62"
+    directory = homeDir("kotlin/kobalt")
+}
+
+ +Here are a few noteworthy details about this small build file: + +
    +
  • You have now declared a variable called kobalt which you can reuse (see below). +
  • You can specify the directory of the project, which means that one build file can be used to build multiple projects. +
  • The functions kotlinProject and homeDir are supplied by Kobalt and are sometimes referred to as "directives" +
+ +

Directives

+ +Now that we have declared a project, we can use it to configure additional steps of our build, such as the packaging: + +
+import com.beust.kobalt.plugin.packaging.packaging
+
+// ...
+
+val packKobalt = packaging(kobalt) {
+    jar {
+    }
+}
+
+ +This is the simplest jar declaration you can have. You can trigger the creation of this jar file by invoking the task "assemble". Note that we passed the kobalt variable to the packaging function, so we make it clear which project we are currently configuring for packaging. The jar directive accepts various settings, so let's be a bit more specific. And let's add a zip file too: + +
+val packKobalt = packaging(kobalt) {
+    jar {
+        fatJar = true
+        manifest {
+            attributes("Main-Class", "com.beust.kobalt.KobaltPackage")
+        }
+    }
+    zip {
+        include("kobaltw")
+        include(from("${kobalt.buildDirectory}/libs"),
+                to("kobalt/wrapper"),
+                "${kobalt.name}-${kobalt.version}.jar",
+                "${kobalt.name}-wrapper.jar")
+    }
+}
+
+ +Our jar file is now declared to be a "fat jar" (which means it will include all its dependencies) and we specified a Main-Class to the jar Manifest, which means we will be able to invoke it with java -jar kobalt-0.61.jar. If you don't like this name, you can override it with a name = "myName.jar" statement. + +

+ +The zip directive follows a similar structure, although here we are specifying which file we want to include. For more details on the packaging plug-in, please see its documentation. + +

Dependencies

+ +You can declare compile and test dependencies as follows: + +
+dependencies {
+    compile("com.beust:jcommander:1.48",
+            "com.beust:klaxon:0.14")
+}
+
+dependenciesTest {
+    compile("org.testng:testng:6.9.5")
+}
+
+ +

Maven repos

+ +Kobalt already knows the location of the most popular Maven repos (Maven Central, JCenter, JBoss) but you can add repos with the repos() directive: + +
+val repos = repos("https://dl.bintray.com/cbeust/maven/")
+
+ +

Using plug-ins

+ +Kobalt comes with a few preconfigured plug-ins but you will want to include external ones as well, which can be downloaded either from a Maven repository (Sonatype, JCenter, ...) or from a local file. + +

+ +First of all, let's take a quick look at the tasks available in the default distribution (your actual output might differ somewhat): + +

+$ ./kobaltw --tasks
+  ===== java =====
+    compile          Compile the project
+    compileTest      Compile the tests
+    test             Run the tests
+    clean            Clean the project
+
+  ===== publish =====
+    generatePom      Generate the .pom file
+    uploadJcenter    Upload the artifacts to JCenter
+
+  ===== packaging =====
+    assemble         Package the artifacts
+
+ +Let's modify our build to include a plug-in. We do this by adding a call to the plugins directive on top of the build file: + +
+val repos = repos("https://dl.bintray.com/cbeust/maven/")
+val p = plugins("com.beust:kobalt-example-plugin:0.42")
+
+ +Now, run the --tasks command again: + +
+$ ./kobaltw --tasks
+  ===== java =====
+    compile         Compile the project
+
+  ===== publish =====
+    generatePom     Generate the .pom file
+    uploadJcenter   Upload the artifacts to JCenter
+
+  ===== kobalt-example-plugin =====
+    coverage        Run coverage
+
+  ===== packaging =====
+    assemble        Package the artifacts
+
+ +Notice the new "coverage" task, provided by the plug-in kobalt-example-plugin that we just included. With the simple action of declaring the plug-in, it is now fully loaded and available right away. Of course, such plug-ins can allow or require additional configuration with their own directives. Please read the plug-in developer documentation for more details. + +

Publishing

+ +Kobalt supports JCenter natively so you can upload your project and make it available on JCenter very easily. + +

+ +First of all, make sure you specified the group, artifactId and version of your project, as required by Maven: + +

+val kobalt = kotlinProject {
+    group = "com.beust"
+    artifactId = "kobalt"
+    version = "0.72"
+
+ +Next, create a file local.properties in the root directory of your project with the following keys: + +
+bintray.user=...
+bintray.apikey=...
+
+ +The values for the user and apikey keys can be found in your bintray profile, as described here. Note that you should not check this local.properties file into your source control (so add it to .gitignore). + +

+ +Make sure that your build creates a jar file (using `packaging`, as explained above). + +

+ +Now, all you need to do is to upload your package: + +

+./gradlew uploadJcenter
+
+ +

Writing a plug-in

+ +A good starting point to write a plug-in is the kobalt-example-plugin project, which shows a minimalistic plug-in. + +

Building

+ +You only need to do two things to build a Kobalt plug-in: + +

1. Add Kobalt as a dependency:

+ +
+dependencies {
+    compile("com.beust:kobalt:0.61")
+}
+
+ +

2. Declare the main class of your plug-in in the Jar file's manifest:

+ +
+val p = packaging(examplePlugin) {
+    jar {
+        manifest {
+            attributes("Kobalt-Plugin-Class", "com.beust.kobalt.example.ExamplePlugin")
+        }
+    }
+}
+
+ +

Implementing

+ +A plug-in typically has three components: + +
    +
  • Extending and implementing the methods of `BasePlugin`. +
  • Specifying one or more tasks. +
  • Specifying directives (functions that will be used from the build file). +
+ +

BasePlugin

+ +The main class of your plugin extends BasePlugin and implements its apply() method and name variable: + +
+public class ExamplePlugin : BasePlugin() {
+    override val name = "kobalt-example-plugin"
+
+    override fun apply(project: Project) {
+        println("Applying plugin ${name} with project ${project}")
+    }
+}
+
+ +

Plugin tasks

+ +Next, you can declare tasks with the @Task annotation: + +
+@Task(name = "coverage", description = "Run coverage",
+    runAfter = arrayOf("compile"))
+public fun coverage(project: Project): TaskResult {
+    println("Running the coverage on project ${project}")
+    return TaskResult()
+}
+
+ +
    +
  • Tasks return a TaskResult object, which can be initialized with false if the task didn't succeed for some reason. +
  • The name of the task is the same name that can be passed to the kobaltw command (e.g. "./kobaltw coverage") +
  • The description is what is displayed with "./kobaltw --tasks" +
  • runAfter and runBefore let you specify the dependencies of your task. In this example plug-in, we want to calculate the coverage of the project so it makes sense to run after the "compile" task. + +

    Directives

    + +Finally, you need to define functions that can be used from the build file (directives). You are encouraged to use the Kotlin DSL approach to expose these functions so that the build file syntax can remain consistent. Typically, these functions will update data that your tasks can then use to do their job. + +

    + +These can be either straight functions or extension functions. For example, here is the kotlinProject directive: + +

    +@Directive
+public fun kotlinProject(init: KotlinProject.() -> Unit): KotlinProject {
+    val result = KotlinProject()
+    result.init()
+    return result
+}
+
    + +This function returns a KotlinProject and the user can then override variables or invoke methods from this class in their build file: + +
    +val kobalt = kotlinProject {
+    name = "kobalt"
+    group = "com.beust"
+...
+
    + +Using an extension function to define a directive allows you to add new functions to Kobalt classes. For example, currently, a project can have "dependencies" and "dependenciesTest". For a coverage plug-in, we would want to add a "dependenciesCoverage" section, which can be easily done by defining an extension function on Project: + +
    +@Directive
+public fun Project.dependenciesCoverage(ini: Dependencies.() -> Unit) : Dependencies {
+    val result = Dependencies()
+    result.init()
+    return result
+}
+
    + +And we can now use: + +
    +val p = kotlinProject {
+    dependenciesCoverage("com.example:foo:0.1")
+}
+```
+
    + + + -
    -
    - Peyto Lake -
    -
    - Train -
    -
    - T-Shirt Store -
    -
    - Mountain -
    -
    -

    Try Resizing your Browser

    -

    - Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. -