From 0a497854948fc0fd391f28cd662cdb5939344569 Mon Sep 17 00:00:00 2001 From: Cedric Beust Date: Thu, 8 Oct 2015 21:26:02 -0700 Subject: [PATCH] Refactoring toc. --- documentation/index.html | 16 ++++++++-------- home/index.html | 8 ++++---- js/kobalt.js | 40 +++++++++++----------------------------- plugins/index.html | 14 +++++++------- 4 files changed, 30 insertions(+), 48 deletions(-) diff --git a/documentation/index.html b/documentation/index.html index 45f3593..787c778 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -102,7 +102,7 @@ As of this writing, Kobalt supports Java and Kotlin projects.

Structure of a build file

-

General concepts

+

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: @@ -129,7 +129,7 @@ Here are a few noteworthy details about this small build file:

  • The functions kotlinProject and homeDir are supplied by Kobalt and are sometimes referred to as "directives" -

    Directives

    +

    Directives

    Now that we have declared a project, we can use it to configure additional steps of our build, such as the assembling it (creating jar and other files: @@ -176,7 +176,7 @@ Our jar file is now declared to be a "fat jar" (which means it will include all 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

    +

    Dependencies

    You can declare compile and test dependencies as follows: @@ -422,7 +422,7 @@ Now, all you need to do is to upload your package: A good starting point to write a plug-in is the kobalt-line-count project, which shows a minimalistic plug-in. -

    Building

    +

    Building

    You only need to do two things to build a Kobalt plug-in: @@ -446,7 +446,7 @@ val p = packaging(examplePlugin) { } -

    Implementing

    +

    Implementing

    A plug-in typically has three components: @@ -456,7 +456,7 @@ A plug-in typically has three components:
  • Specifying directives (functions that will be used from the build file). -

    BasePlugin

    +

    BasePlugin

    The main class of your plugin extends BasePlugin and implements its apply() method and name variable: @@ -472,7 +472,7 @@ public class ExamplePlugin : BasePlugin() { } -

    Plugin tasks

    +

    Plugin tasks

    Next, you can declare tasks with the @Task annotation: @@ -494,7 +494,7 @@ public fun coverage(project: Project): TaskResult {

  • 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

    +

    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. diff --git a/home/index.html b/home/index.html index 78d32a0..9634ece 100644 --- a/home/index.html +++ b/home/index.html @@ -119,7 +119,7 @@ Kobalt is complete enough to build three of my personal projects (1. Scratching an itch +

    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. @@ -134,19 +134,19 @@ I suspect a part of it is due to Groovy which, even though it started gaining so

  • Building is slow and hard to diagnose because of Gradle's mixed Java/Groovy code base. -

    2. An experiment

    +

    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

    +

    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

    +

    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. diff --git a/js/kobalt.js b/js/kobalt.js index e70a3cc..c15551e 100644 --- a/js/kobalt.js +++ b/js/kobalt.js @@ -56,45 +56,26 @@ function generateNavBar(index) { // Table of contents // -function countersToHeading(counters) { - var result = ""; - for (var i = 0; i < counters.length; i++) { - if (i > 0) result = result + "."; - result = result + counters[i]; - } - return result; -} - -function indentSection(count) { - var result = ""; - for (var i = 0; i < count; i++) { - result += "  "; - } - return result; -} - -function rewriteSection(section, counters) { - var result = ""; - result = result + countersToHeading(counters) + " - " + section.innerHTML; - return result; -} - function generateToc() { var sections = document.getElementsByClassName("section"); var toc = '';//