mirror of
https://github.com/ethauvin/kobalt-doc.git
synced 2025-04-24 19:47:11 -07:00
557 lines
27 KiB
HTML
557 lines
27 KiB
HTML
<html>
|
|
<head>
|
|
<title>
|
|
|
|
Kobalt, by Cedric Beust
|
|
|
|
</title>
|
|
|
|
<!-- Bootstrap core CSS -->
|
|
|
|
<link href="../bootstrap/dist/css/bootstrap.min.css" rel="stylesheet">
|
|
<link href="../css/kobalt.css" rel="stylesheet" />
|
|
|
|
<!-- Optional Bootstrap Theme -->
|
|
|
|
<link href="data:text/css;charset=utf-8," data-href="../bootstrap/dist/css/bootstrap-theme.min.css" rel="stylesheet" id="bs-theme-stylesheet">
|
|
|
|
|
|
<!--[if lt IE 9]><script src="../assets/js/ie8-responsive-file-warning.js"></script><![endif]-->
|
|
<!--
|
|
<script src="../bootstrap/assets/js/ie-emulation-modes-warning.js"></script>
|
|
-->
|
|
|
|
<!-- HTML5 shim and Respond.js for IE8 support of HTML5 elements and media queries -->
|
|
<!--[if lt IE 9]>
|
|
<script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
|
|
<script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
|
|
<![endif]-->
|
|
|
|
<!-- Favicons -->
|
|
<!--
|
|
<link rel="icon" href="/favicon.ico">
|
|
-->
|
|
|
|
</head>
|
|
|
|
<body>
|
|
|
|
|
|
<div class="container">
|
|
|
|
<!-- Static navbar -->
|
|
<nav id="kobalt-navbar" class="navbar navbar-default">
|
|
</nav>
|
|
|
|
<!-- Main component for a primary marketing message or call to action -->
|
|
<div class="jumbotron">
|
|
<h1>Plug-in development</h1>
|
|
<p>How to write a Kobalt plug-in.</p>
|
|
</div>
|
|
|
|
<!-- Main content -->
|
|
<div class="col-md-9">
|
|
|
|
<h2 class="section" id="introduction">Introduction</h2>
|
|
|
|
<p>
|
|
Kobalt plug-ins are usually made of several parts:
|
|
|
|
<ul>
|
|
<li><a href="#plugin-xml"><b>kobalt-plugin.xml</b></a>. A file that describes all the components (called "plug-in actors") of your plug-in, such as contributors.</li>
|
|
<li><a href="#directives"><b>Directives</b></a>. Kotlin functions that users of your plug-in can invoke in their build file, such as <code>kotlinProject</code> or <code>dependencies</code>. These functions typically configure some data that your plug-in will later use to perform its functions.</li>
|
|
<li><a href="#tasks"><b>Tasks</b></a>. These tasks are invoked from the command line and ask your plug-ins to perform certain actions.</li>
|
|
<li><a href="#properties"><b>Properties</b></a>. Plug-ins can export properties and read properties from other plug-ins.</li>
|
|
</ul>
|
|
</p>
|
|
<p>
|
|
If you are curious to get a quick feel for what a Kobalt plug-in looks like, I suggest you go read how to
|
|
<a href="../ten-minutes/index.html">write and publish a plug-in in ten minutes</a> and then you can come back here
|
|
and keep reading.
|
|
</p>
|
|
|
|
<h2 class="section" id="kobalt-plugin-xml">kobalt-plugin.xml</h2>
|
|
<p>
|
|
The <code>kobalt-plugin.xml</code> file (stored in <code>META-INF</code> in the jar file of your plug-in) is mandatory and describes all the actors of your plug-in. This file contains a list of class names, each of which is expected to implement at least one of <code>IPluginActor</code>'s interfaces:
|
|
</p>
|
|
<pre>
|
|
<kobalt-plugin>
|
|
<name>kobalt</name>
|
|
<plugin-actors>
|
|
<class-name>com.beust.kobalt.plugin.android.AndroidPlugin</class-name>
|
|
<class-name>com.beust.kobalt.plugin.java.JavaBuildGenerator</class-name>
|
|
</plugin-actors>
|
|
</kobalt-plugin>
|
|
</pre>
|
|
|
|
<p>
|
|
<code>IPluginActors</code> can be split in several categories:
|
|
</p>
|
|
<ul>
|
|
<li><strong>Plugins</strong>, which contain <code>@Task</code> annotations.</li>
|
|
<li><strong>Interceptors</strong>, which transform data that Kobalt gives them.</li>
|
|
<li><strong>Contributors</strong>, which produce additional data.</li>
|
|
</ul>
|
|
<p>
|
|
All plug-in actors are interfaces that extend <code>IPluginActor</code>. Plug-ins extend <code>IPlugin</code>,
|
|
interceptors extend <code>IInterceptor</code> and contributors extend <code>IContributor</code>. When Kobalt parses your
|
|
<code>kobalt-plugin.xml</code>, it instantiates all the classes found in the <code><plugin-actors></code> tag
|
|
and then introspects them to find out which <code>IPluginActor</code> interfaces that class implements.
|
|
|
|
</p>
|
|
|
|
<h3 class="section" id="philosophy">Plug-in architecture philosophy</h3>
|
|
<p>
|
|
<p>
|
|
Plug-ins often produce files and data that other plug-ins need to use in order for a build to succeed. For example,
|
|
the Android plug-in needs to generate a file called <code>R.java</code> and then make this file available at
|
|
compile time by the Java or Kotlin (or any other language) plug-in. Since plug-ins have no idea about what other
|
|
plug-ins are currently enabled and running, they can't directly talk to each other so instead of calling into
|
|
Kobalt, Kobalt calls into them. This is done by declaring various "actors" that Kobalt will invoke whenever
|
|
it needs the information that your plug-in produced. This is a design pattern often referred to as the
|
|
<a href="https://en.wikipedia.org/wiki/Hollywood_principle">"Hollywood Principle"</a>: "Don't call us, we'll call you".
|
|
</p>
|
|
<p>
|
|
These "actors" are exactly what the <code>kobalt-plugin.xml</code> file describes. This file informs Kobalt about
|
|
the various ways in which your plug-in participates in the build system by specifying 1) plug-ins, 2) contributors
|
|
or 3) interceptors.
|
|
|
|
</p>
|
|
</p>
|
|
|
|
<h2 class="section" id="actor-list">List of plug-in actors</h2>
|
|
<p>
|
|
Here is a list of actors (contributors and interceptors) that you can define in your plug-in.
|
|
</p>
|
|
<table class="table table-bordered table-condensed">
|
|
<thead>
|
|
<td>Interface name</td>
|
|
<td>Type</td>
|
|
<td>Description</td>
|
|
</thead>
|
|
<tr>
|
|
<td><code><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IBuildDirectoryInterceptor.kt">IBuildDirectoryInterceptor</a></code></td>
|
|
<td><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IPluginActor.kt"><code>IInterceptor</code></a> </td>
|
|
<td>
|
|
Plug-ins that need to generate class files in a different directory than the default one should
|
|
implement this interface.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IClasspathContributor.kt">IClasspathContributor
|
|
</a></code></td>
|
|
<td><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IPluginActor.kt"><code>IContributor</code></a> </td>
|
|
<td> Classpath contributors let you specify additional jar files or directories that will be used by
|
|
the <code>"compile"</code> task.
|
|
</td>
|
|
|
|
</tr>
|
|
<tr>
|
|
<td><code><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IClasspathInterceptor.kt">IClasspathInterceptor
|
|
</a></code></td>
|
|
<td><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IPluginActor.kt"><code>IInterceptor</code></a> </td>
|
|
<td>
|
|
Plug-ins that want to modify the classpath before Kobalt uses it should implement this interface.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/ICompilerContributor.kt">ICompilerContributor</a></code></td>
|
|
<td><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IPluginActor.kt"><code>IContributor</code></a> </td>
|
|
<td>
|
|
Plug-ins that know how to turn files into bytecodes should implement this interface.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/ICompilerInterceptor.kt">ICompilerInterceptor</a></code></td>
|
|
<td><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IPluginActor.kt"><code>IInterceptor</code></a> </td>
|
|
<td>
|
|
Plug-ins that implement this interface get a chance to alter the dependencies of a project (<code>dependencies{}</code>, <code>dependenciesTest{}</code>, ...) before Kobalt sees them.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IDocContributor.kt">IDocContributor</a></code></td>
|
|
<td><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IPluginActor.kt"><code>IContributor</code></a> </td>
|
|
<td>
|
|
Plug-ins that know how to generate documentation out of source files should implement this interface.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IInitContributor.kt">IInitContributor</a></code></td>
|
|
<td><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IPluginActor.kt"><code>IContributor</code></a> </td>
|
|
<td>Kobalt supports the <code>--init</code> command line parameter, which generates a default build file
|
|
based on the files found in the current directory. Any plug-in that wants to be part of this process need
|
|
to implement this interface. In this case, both the Java and Kotlin plug-ins define such a contributor
|
|
but future plug-ins might use this contributor to generate their own build file: Android, Ceylon, Spring, etc...
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IProjectContributor.kt">IProjectContributor</a></code></td>
|
|
<td><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IPluginActor.kt"><code>IContributor</code></a> </td>
|
|
<td>Some plug-ins produce projects (Java, Kotlin) while others don't (Packaging, Application, etc...). The ones that
|
|
do need to register themselves as project contributors. This is how Kobalt collects all the projects defined
|
|
after a build file was parsed.</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IRepoContributor.kt">IRepoContributor</a></code></td>
|
|
<td><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IPluginActor.kt"><code>IContributor</code></a> </td>
|
|
<td>
|
|
Some plug-ins might want to add their own repository to the list of repositories that Kobalt already supports.
|
|
This is the case of the Android plug-in which, once the <code>ANDROID_HOME</code> environment variable has been
|
|
defined, will automatically add the repository inside the Android distribution so that support libraries and other
|
|
artifacts can be found.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/ISourceDirectoriesInterceptor.kt">
|
|
ISourceDirectoriesInterceptor</a></code></td>
|
|
<td><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IPluginActor.kt"><code>IInterceptor</code></a> </td>
|
|
<td>
|
|
Plug-ins that wamt to add, remove or alter the source directories should implement this interface.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IRunnerContributor.kt">IRunnerContributor</a></code></td>
|
|
<td><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IPluginActor.kt"><code>IContributor</code></a> </td>
|
|
<td>
|
|
Plug-ins that can operate when the <code>"run"</code> task gets invoked should implement that interface.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><code><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/ITestRunnerContributor.kt">
|
|
ITestRunnerContributor</a></code></td>
|
|
<td><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/IPluginActor.kt"><code>IContributor</code></a> </td>
|
|
<td>
|
|
Plug-ins that can operate when the <code>"test"</code> task gets invoked should implement that interface.
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h2 class="section" id="example">Example</h2>
|
|
<p>
|
|
Kobalt itself uses a <code>kobalt-plugin.xml</code> to define contributors and interceptors, here is
|
|
an excerpt of it:
|
|
</p>
|
|
<pre>
|
|
<plugin-actors>
|
|
<class-name>com.beust.kobalt.plugin.java.JavaPlugin</class-name>
|
|
<class-name>com.beust.kobalt.plugin.android.AndroidPlugin</class-name>
|
|
|
|
<class-name>com.beust.kobalt.plugin.java.JavaBuildGenerator</class-name>
|
|
<class-name>com.beust.kobalt.plugin.kotlin.KotlinBuildGenerator</class-name>
|
|
</plugin-actors>
|
|
</pre>
|
|
<p>
|
|
In order to find out what these actually do, we just need to take a look at their definition and
|
|
see which interfaces they implement. For example:
|
|
</p>
|
|
<pre>
|
|
class JavaPlugin : ICompilerContributor, IDocContributor {</pre>
|
|
|
|
<p>
|
|
With this declaration, we know that the <code>JavaPlugin</code> contributes a compiler and a doc generator.
|
|
</p>
|
|
<pre>
|
|
class JavaBuildGenerator: IInitContributor {</pre>
|
|
<p>
|
|
This class is declaring that it wants to take part in the <code>--init</code> selection process, which is
|
|
discussed in the next section.
|
|
</p>
|
|
<h2 class="section" id="selection-process">Selection process</h2>
|
|
<p>
|
|
Several plug-ins might want to contribute to a specific task where only one participant should be allowed,
|
|
such as running tests or generating documentation. Even the simple task of compiling should probably only
|
|
ever be performed by no more than one plug-in for a given project. Therefore, when comes the time to
|
|
compile a project,
|
|
Kobalt needs to find which plug-in is the most suitable for that task and pick it. In order to do that,
|
|
plug-ins that contribute to tasks that can only be performed by one candidate need to declare their
|
|
<em>affinity</em> to that task for a given project.
|
|
</p>
|
|
<p>
|
|
Contributors that want to participate in a selection process need to implement the following interface:
|
|
</p>
|
|
<pre>
|
|
interface IProjectAffinity {
|
|
/**
|
|
* @return an integer indicating the affinity of your actor for the given project. The actor that returns
|
|
* the highest affinity gets selected.
|
|
*/
|
|
fun affinity(project: Project, context: KobaltContext) : Int
|
|
}</pre>
|
|
<p>
|
|
For example, the JavaPlugin implements the <code><a href="https://github.com/cbeust/kobalt/blob/master/src/main/kotlin/com/beust/kobalt/api/ICompilerContributor.kt">ICompilerContributor</a></code> interface and then overrides
|
|
the <code>affinity()</code> method to make sure it gets run for Java projects but ignored for others:
|
|
</p>
|
|
|
|
<pre>
|
|
override fun affinity(project: Project, context: KobaltContext) =
|
|
if (project.sourceSuffix == ".java") 1 else 0</pre>
|
|
|
|
|
|
<h2 class="section" id="directives">Directives</h2>
|
|
<p>
|
|
Directives are functions that users of your plug-in can use in their build file in order to configure your plug-in. These can be any kind of Kotlin function but in the interest of preserving a clean syntax in the build file, it's recommended to use the type safe builder pattern, <a href="https://kotlinlang.org/docs/reference/type-safe-builders.html">as described here</a>.
|
|
</p>
|
|
<p>
|
|
Imagine that you want to offer a boolean parameter <code>publish</code> to users of your plug-in, you start by creating a class to hold that parameter:
|
|
</p>
|
|
<pre>
|
|
class Info(val publish: Boolean)
|
|
</pre>
|
|
<p>
|
|
Next, you create a directive that returns such a class and which also allows to configure it via the type safe builder pattern:
|
|
</p>
|
|
<pre>
|
|
@Directive
|
|
public fun myConfig(init: Info.() -> Unit) = Info().apply { init() }</pre>
|
|
<p>
|
|
The <code>@Directive</code> annotation is not enforced but you should always use it in order to help future tools (e.g. an IDEA plug-in) identify Kobalt directives so they can be treated differently from regular Kotlin functions. The code above defines a <code>myConfig</code> function that accepts a closure as an argument. It creates an <code>Info</code>
|
|
object, calls the <code>init()</code> function on it (which runs all the code inside that closure) and then return that <code>Info</code> object.
|
|
</p>
|
|
<p>
|
|
Users can now specify the following in their build file:
|
|
</p>
|
|
<pre>
|
|
// Build.kt
|
|
import.com.example.plugin.myConfig
|
|
|
|
myConfig {
|
|
publish = true
|
|
}</pre>
|
|
<p>
|
|
If you need access to the project being built, just declare an additional parameter of type <code>Project</code> to your directive and have the user pass that project:
|
|
</p>
|
|
<pre>
|
|
@Directive
|
|
public fun myConfig(project: Project, init: Info.() -> Unit) : Info {
|
|
// ...
|
|
</pre>
|
|
<pre>
|
|
myConfig(project) {
|
|
publish = true
|
|
}
|
|
</pre>
|
|
<p>
|
|
The last piece of this puzzle is how you give this data back to your plug-in so it can act on it. In order to do this, you simply look up the name of your plug-in in the <code>Plugins</code> registry and invoke whatever function you need to run:
|
|
</p>
|
|
|
|
<pre>
|
|
@Directive
|
|
public fun myConfig(init: Info.() -> Unit) = Info().apply {
|
|
init()
|
|
(Kobalt.findPlugin("my-plug-in") as MyPlugin).info = info
|
|
this
|
|
}</pre>
|
|
<p>
|
|
Obviously, you can choose any kind of API to communicate between the directive and its plug-in. In the code
|
|
above, I chose to directly override the entire <code>Info</code> field, but you could instead choose to call
|
|
a function, just set one boolean instead of the whole object, etc...
|
|
</p>
|
|
<h2 class="section" id="tasks">Tasks</h2>
|
|
<p>
|
|
Tasks are provided by plug-ins and can be invoked from the command line, e.g. <code>./kobaltw assemble</code>. There are two kinds of tasks: static and dynamic.
|
|
</p>
|
|
<h3 class="section" indent="1">Static tasks</h3>
|
|
<p>
|
|
Static tasks are functions declared directly in your plug-in class and annotated with the <code>@Task</code> annotation. Here is an example:
|
|
</p>
|
|
<pre>
|
|
@Task(name = "lineCount", description = "Count the lines", runBefore = arrayOf("compile"))
|
|
fun lineCount(project: Project): TaskResult {
|
|
// ...
|
|
return TaskResult()
|
|
}
|
|
</pre>
|
|
<p>
|
|
A Kobalt task needs to accept a <code>Project</code> in parameter and return a <code>TaskResult</code>, which indicates whether this task completed successfully.
|
|
</p>
|
|
|
|
<p>
|
|
The <code>@Task</code> annotation accepts the following attributes:
|
|
<dl class="dl-horizontal">
|
|
<dt>name</dt>
|
|
<dd>The name of the task, which will be used to invoke it from the command line.</dd>
|
|
<dt>description</dt>
|
|
<dd>The description of this command, which will be displayed if the user invokes the usage for the <code>gradlew</code> command.</dd>
|
|
<dt>runBefore</dt>
|
|
<dd>A list of all the tasks that this task should run prior to.</dd>
|
|
<dt>runAfter</dt>
|
|
<dd>A list of all the tasks that should run before this task does.</dd>
|
|
<dt>alwaysRunAfter</dt>
|
|
<dd>A list of all the tasks that will always be run after this task if it's invoked.</dd>
|
|
</dl>
|
|
</p>
|
|
<p>
|
|
The difference between <code>runAfter</code> and <code>alwaysRunAfter</code> is subtle but important. <code>runAfter</code>
|
|
is just a declaration of dependency. It's basically the reverse of <code>runBefore</code> but it's useful in case
|
|
you are not the author of the task you want to run before (if you were, you would just use the <code>runBefore</code>
|
|
annotation on it). Since you can't say <code>"a runBefore b"</code> because you don't own task "a",
|
|
you say <code>"b runAfter a"</code>.
|
|
</p>
|
|
<p>
|
|
For example, <code>compileTest</code> is declared as a <code>runAfter</code> for the task <code>compile</code>.
|
|
This means that it doesn't make sense to run <code>compileTest</code> unless <code>compile</code> has run first.
|
|
However, if a user invokes the task <code>compile</code>, they probably don't want to invoke <code>compileTest</code>,
|
|
so a dependency is exactly what we need here: invoking <code>compileTest</code> will trigger <code>compile</code>
|
|
but not the other way around.
|
|
</p>
|
|
<p>
|
|
However, there are times where you want to define a task that will <strong>always</strong> run after a given task.
|
|
For example, you could have a <code>signJarFile</code> task that should always be invoked if someone builds a jar
|
|
file. You don't expect users to invoke that target explicitly, but whenever they invoke the <code>assemble</code>
|
|
target, you want your <code>signJarFile</code> target to be invoked. When you want such a task to always be invoked
|
|
even if the user didn't explicitly request it, you should use <code>alwaysRunAfter</code>.
|
|
Note that there is no <code>alwaysRunBefore</code> annotation since <code>runBefore</code>
|
|
achieves the same functionality.
|
|
</p>
|
|
<p>
|
|
Here are a few different scenarios to illustrate how the three attributes work for the task <code>exampleTask</code>:
|
|
</p>
|
|
<p align="center">
|
|
<strong>Result of the command <code>./kobaltw --dryRun compile</code></strong>
|
|
</p>
|
|
<table width="100%" class="table table-bordered table-condensed">
|
|
<thead>
|
|
<td align="center">Configuration for <code>exampleTask</code></td>
|
|
<td align="center">Result</td>
|
|
</thead>
|
|
|
|
<tr>
|
|
<td align="center">runBefore = "compile"</td>
|
|
<td>
|
|
<pre>kobalt-line-count:clean
|
|
kobalt-line-count:exampleTask
|
|
kobalt-line-count:compile</pre>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center">runAfter = "compile"</td>
|
|
<td>
|
|
<pre>kobalt-line-count:clean
|
|
kobalt-line-count:compile</pre>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center">alwaysRunAfter = "compile"</td>
|
|
<td>
|
|
<pre>kobalt-line-count:clean
|
|
kobalt-line-count:compile
|
|
kobalt-line-count:exampleTask</pre>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<h3 class="section" indent="1">Dynamic tasks</h3>
|
|
|
|
<p>
|
|
Dynamic tasks are useful when you want your plug-in to generate one or several tasks that depend on
|
|
some other runtime information (therefore, you can't declare a method and put a <code>@Task</code>
|
|
annotation on it). Plug-ins declare dynamic tasks by implementing the <code>ITaskContributor</code>
|
|
intrface:
|
|
</p>
|
|
<pre>
|
|
interface ITaskContributor {
|
|
fun tasksFor(context: KobaltContext) : List<DynamicTask>
|
|
}</pre>
|
|
<p>
|
|
For example:
|
|
</p>
|
|
<pre>
|
|
override fun tasksFor(context: KobaltContext) = listOf(
|
|
DynamicTask(
|
|
name = "dynamicTask",
|
|
description = "Description",
|
|
alwaysRunAfter = listOf("compile"),
|
|
closure = { project: Project ->
|
|
println("Running dynamicTask")
|
|
TaskResult()
|
|
}))</pre>
|
|
<p>
|
|
<code>DynamicTask</code> mirrors the <code>@Task</code> attributes: <code>name</code>, <code>description</code> and
|
|
dependencies. The only addition is the <code>closure</code> parameter, which specifics the code that will
|
|
run if your task gets invoked. That closure needs to follow the same constraints that a <code>@Task</code> method
|
|
obeys: it takes a <code>Project</code> parameter and returns a <code>TaskResult</code>.
|
|
</p>
|
|
<p>
|
|
Once you have implemented <code>ITaskContributor</code>, you can see your dynamic task in the list of tasks and run it directly:
|
|
</p>
|
|
<pre>
|
|
$ ./kobaltw --tasks
|
|
===== kobalt-line-count =====
|
|
dynamicTask Description
|
|
lineCount Count the lines
|
|
$ ./kobaltw dynamicTask
|
|
Running dynamictask
|
|
</pre>
|
|
|
|
<h2 class="section" id="properties">Properties</h2>
|
|
<p>
|
|
Properties are the mechanism that plug-ins can use to export values and also read values that other
|
|
plug-ins have exported. There are two kinds of properties that plug-ins can manipulate:
|
|
</p>
|
|
<ul>
|
|
<li><strong>Project properties</strong>: project-specific properties.</li>
|
|
<li><strong>Plug-in properties</strong>: general properties that are applicable to no project
|
|
in particular.</li>
|
|
</ul>
|
|
<h3 class="section" indent="1" id="project-properties">Project properties</h3>
|
|
|
|
<p>
|
|
<code>Project</code> instances have a property called <code>projectProperties</code> that is an
|
|
instance of the <code>ProjectProperties</code> class. Plugins can put and get values on this
|
|
object in order to store project specific properties.
|
|
</p>
|
|
<pre class="brush:java">
|
|
fun taskAssemble(project: Project) : TaskResult {
|
|
project.projectProperties.put(PACKAGES, packages)
|
|
</pre>
|
|
<h3 class="section" indent="1" id="plugin-properties">Plug-in properties</h3>
|
|
<p>
|
|
The <code>PluginProperties</code> instance can be found on the <code>KobaltContext</code>
|
|
object that your plug-in receives in its <code>apply()</code> method. Once you have an instance of this
|
|
class, you can read or write variables into it:
|
|
</p>
|
|
<pre>
|
|
override fun apply(project: Project, context: KobaltContext) {
|
|
// Export a property for other plug-ins to use
|
|
context.pluginProperties.put(PLUGIN_NAME, "somePluginProperty", "someValue")
|
|
|
|
// Read a property from another plug-in
|
|
val sourceDir = context.pluginProperties.get("pluginName", "somePluginProperty")
|
|
}
|
|
</pre>
|
|
|
|
<h3 class="section" indent="1" id="documenting-properties">Documenting properties</h3>
|
|
|
|
<p>
|
|
Plug-ins that define properties should annotate them with the <code>@ExportedPluginProperty</code> or
|
|
<code>@ExportedProjectProperty</code>annotation:
|
|
</p>
|
|
<pre>
|
|
companion object {
|
|
@ExportedProjectProperty
|
|
const val BUILD_DIR = "buildDir"
|
|
</pre>
|
|
|
|
</div>
|
|
<!-- Table of contents -->
|
|
<div class="col-md-3" id="table-of-contents">
|
|
</div>
|
|
|
|
<!-- Bootstrap core JavaScript
|
|
================================================== -->
|
|
<!-- Placed at the end of the document so the pages load faster -->
|
|
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
|
|
<script src="../bootstrap/dist/js/bootstrap.min.js"></script>
|
|
<script src="../js/kobalt.js"></script>
|
|
<script>generateKobalt(3);</script>
|
|
|
|
<!--
|
|
<script src="../bootstrap/dist/js/docs.min.js"></script>
|
|
-->
|
|
<!-- IE10 viewport hack for Surface/desktop Windows 8 bug -->
|
|
<!--
|
|
<script src="../../assets/js/ie10-viewport-bug-workaround.js"></script>
|
|
-->
|
|
|
|
</div>
|
|
</body>
|