mirror of
https://github.com/ethauvin/kobalt-doc.git
synced 2025-04-25 12:07:10 -07:00
Refactoring toc.
This commit is contained in:
parent
6392d6965c
commit
0a49785494
4 changed files with 30 additions and 48 deletions
|
@ -102,7 +102,7 @@ As of this writing, Kobalt supports Java and Kotlin projects.
|
|||
|
||||
<h2 class="section" id="structure">Structure of a build file</h2>
|
||||
|
||||
<h3 class="section" indent=".." id="general-concepts">General concepts</h3>
|
||||
<h3 class="section" indent="1" id="general-concepts">General concepts</h3>
|
||||
|
||||
<p>
|
||||
The build file is typically called <code>Built.kt</code> 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:
|
|||
<li>The functions <code>kotlinProject</code> and <code>homeDir</code> are supplied by Kobalt and are sometimes referred to as "directives"
|
||||
</ul>
|
||||
|
||||
<h3 class="section" indent=".." id="directives">Directives</h3>
|
||||
<h3 class="section" indent="1" id="directives">Directives</h3>
|
||||
|
||||
<p>
|
||||
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 <code>packaging</code> plug-in, please see its documentation.
|
||||
</p>
|
||||
|
||||
<h3 class="section" indent=".." id="dependencies">Dependencies</h3>
|
||||
<h3 class="section" indent="1" id="dependencies">Dependencies</h3>
|
||||
|
||||
<p>
|
||||
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 <a href="https://github.com/cbeust/kobalt-line-count">kobalt-line-count project</a>, which shows a minimalistic plug-in.
|
||||
|
||||
<h3 class="section" indent=".." id="building">Building</h3>
|
||||
<h3 class="section" indent="1" id="building">Building</h3>
|
||||
|
||||
You only need to do two things to build a Kobalt plug-in:
|
||||
|
||||
|
@ -446,7 +446,7 @@ val p = packaging(examplePlugin) {
|
|||
}
|
||||
</pre>
|
||||
|
||||
<h3 class="section" indent=".." id="implementing">Implementing</h3>
|
||||
<h3 class="section" indent="1" id="implementing">Implementing</h3>
|
||||
|
||||
A plug-in typically has three components:
|
||||
|
||||
|
@ -456,7 +456,7 @@ A plug-in typically has three components:
|
|||
<li>Specifying directives (functions that will be used from the build file).
|
||||
</ul>
|
||||
|
||||
<h3 class="section" indent=".." id="base-plugin">BasePlugin</h3>
|
||||
<h3 class="section" indent="1" id="base-plugin">BasePlugin</h3>
|
||||
|
||||
<p>
|
||||
The main class of your plugin extends <code>BasePlugin</code> and implements its <code>apply()</code> method and <code>name</code> variable:
|
||||
|
@ -472,7 +472,7 @@ public class ExamplePlugin : BasePlugin() {
|
|||
}
|
||||
</pre>
|
||||
|
||||
<h3 class="section" indent=".." id="plugin-tasks">Plugin tasks</h3>
|
||||
<h3 class="section" indent="1" id="plugin-tasks">Plugin tasks</h3>
|
||||
|
||||
<p>
|
||||
Next, you can declare tasks with the <code>@Task</code> annotation:
|
||||
|
@ -494,7 +494,7 @@ public fun coverage(project: Project): TaskResult {
|
|||
<li><code>runAfter</code> and <code>runBefore</code> 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 <code>"compile"</code> task.
|
||||
</ul>
|
||||
|
||||
<h3 class="section" indent=".." id="plugin-directives">Directives</h3>
|
||||
<h3 class="section" indent="1" id="plugin-directives">Directives</h3>
|
||||
|
||||
<p>
|
||||
Finally, you need to define functions that can be used from the build file (directives). You are encouraged to use the <a href="https://confluence.jetbrains.com/display/Kotlin/Type-safe+Groovy-style+builders">Kotlin DSL approach</a> 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.
|
||||
|
|
|
@ -119,7 +119,7 @@ Kobalt is complete enough to build three of my personal projects (<a href="https
|
|||
|
||||
With this disclaimer, why did I decide to write Kobalt?
|
||||
|
||||
<h3 class="section" indent="..">1. Scratching an itch</h3>
|
||||
<h3 class="section" indent="1">1. Scratching an itch</h3>
|
||||
|
||||
<p>
|
||||
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
|
|||
<li>Building is slow and hard to diagnose because of Gradle's mixed Java/Groovy code base.
|
||||
</ul>
|
||||
|
||||
<h3 class="section" indent="..">2. An experiment</h3>
|
||||
<h3 class="section" indent="1">2. An experiment</h3>
|
||||
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<h3 class="section" indent="..">3. A proof of concept</h3>
|
||||
<h3 class="section" indent="1">3. A proof of concept</h3>
|
||||
|
||||
<p>
|
||||
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".
|
||||
</p>
|
||||
|
||||
<h3 class="section" indent="..">4. An excuse to write Kotlin</h3>
|
||||
<h3 class="section" indent="1">4. An excuse to write Kotlin</h3>
|
||||
|
||||
<p>
|
||||
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.
|
||||
|
|
40
js/kobalt.js
40
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 = '';//<ul class="nav">\n';
|
||||
var counters = new Array();
|
||||
var currentLevel = 0;
|
||||
var currentLevel = -1;
|
||||
for (i = 0; i < sections.length; i++) {
|
||||
var section = sections[i];
|
||||
var nameNode = section.attributes["name"];
|
||||
var name = nameNode ? nameNode.nodeValue : i;
|
||||
var indentNode = section.attributes["indent"];
|
||||
var indent = indentNode ? indentNode.nodeValue : ".";
|
||||
var ind = 0;
|
||||
var indentAttribute = section.attributes["indent"];
|
||||
if (indentAttribute) {
|
||||
ind = indentAttribute.textContent;
|
||||
}
|
||||
if (! ind) ind = 0;
|
||||
console.log("ind: " + ind + " level:" + currentLevel);
|
||||
var currentCounter = 0;
|
||||
var ind = indent.length;
|
||||
if (ind > currentLevel) {
|
||||
if (ind == 1) {
|
||||
if (ind == 0) {
|
||||
toc += '<ul class="nav">\n';
|
||||
} else {
|
||||
toc += '<ul>\n';
|
||||
|
@ -106,7 +87,8 @@ function generateToc() {
|
|||
currentLevel = ind;
|
||||
}
|
||||
toc += "</ul>\n";
|
||||
|
||||
|
||||
console.log(toc);
|
||||
var tocId = "table-of-contents";
|
||||
var tocTag = document.getElementById(tocId);
|
||||
|
||||
|
|
|
@ -72,7 +72,7 @@ val p = javaProject(wrapper) {
|
|||
Both these directives allow you to consider an object of type <code><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/Project.kt">Project</code></a>.
|
||||
</p>
|
||||
|
||||
<h3 class="section" indent="..">Project</h3>
|
||||
<h3 class="section" indent="1">Project</h3>
|
||||
|
||||
<p>
|
||||
A <code>Project</code> has two mandatory attributes: <code>name</code> and <code>version</code>. If you are planning to deploy your project to a Maven repository, you also have to specify its <code>group</code> (e.g. <code>com.beust</code>) and <code>artifactId</code> (e.g. <code>kobalt</code>).
|
||||
|
@ -92,7 +92,7 @@ A <code>Project</code> has two mandatory attributes: <code>name</code> and <code
|
|||
<dd>The dependencies for your tests</dd>
|
||||
</dl>
|
||||
|
||||
<h3 class="section" indent="..">Tasks</h3>
|
||||
<h3 class="section" indent="1">Tasks</h3>
|
||||
<p>
|
||||
Once you have at least one project configured, the plug-in lets you invoke the following tasks:
|
||||
<dl class="dl-horizontal">
|
||||
|
@ -122,13 +122,13 @@ val packaging = assemble(kobalt) {
|
|||
If you don't specify a <code>name</code> for your archive, a default one will be used that contains your project name, version and the corresponding suffix, e.g. <code>kobalt-1.1.jar</code> or <code>sec-0.2.war</code>.
|
||||
</p>
|
||||
|
||||
<h3 class="section" indent="..">zip</h3>
|
||||
<h3 class="section" indent="1">zip</h3>
|
||||
|
||||
<p>
|
||||
All these archives are zip files, so the <code>zip</code> archive is at the top of the hierarchy and <code>jar</code> and <code>war</code> inherit all its attributes, which include <code>name</code>, <code>include</code> and <code>exclude</code>.
|
||||
</p>
|
||||
|
||||
<h3 class="section" indent="..">include and exclude</h3>
|
||||
<h3 class="section" indent="1">include and exclude</h3>
|
||||
|
||||
<p>
|
||||
All archives let you include and exclude files.
|
||||
|
@ -153,7 +153,7 @@ val a = assemble(kobalt) {
|
|||
The first form, with just one parameter, simply copies the file from your directory into the archive, preserving its path. The second form has three parameters which allow you to move the file to a different path into your archive. Note the use of the <code>from</code>, <code>to</code> and <code>glob</code> directives, which are necessary to disambiguate the call.
|
||||
</p>
|
||||
|
||||
<h3 class="section" indent="..">jar</h3>
|
||||
<h3 class="section" indent="1">jar</h3>
|
||||
|
||||
<p>
|
||||
A <code>jar</code> is like a <code>zip</code> with two additional available parameters:
|
||||
|
@ -182,13 +182,13 @@ val a = assemble(kobalt) {
|
|||
</pre>
|
||||
|
||||
|
||||
<h3 class="section" indent="..">war</h3>
|
||||
<h3 class="section" indent="1">war</h3>
|
||||
|
||||
<p>
|
||||
The <code>war</code> directive generates a war file suitable to be deployed into a servlet container.
|
||||
</p>
|
||||
|
||||
<h3 class="section" indent="..">mavenJars</h3>
|
||||
<h3 class="section" indent="1">mavenJars</h3>
|
||||
|
||||
<p>
|
||||
The <code>mavenJars</code> directive generates several jar files (binary, source, javadoc) which are required by Maven repositories. It's basically a shortcut that saves you the trouble from having to assemble these jar files manually in your build file. It allows you to specify Manifest attributes, just like the <code>jar</code> directive.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue