mirror of
https://github.com/ethauvin/kobalt-doc.git
synced 2025-04-25 12:07:10 -07:00
Indenting.
This commit is contained in:
Cedric Beust
parent
67ff327fd2
commit
f24a883b22
1 changed files with 214 additions and 214 deletions
|
|
@ -30,54 +30,54 @@
|
||||||
<link rel="icon" href="/favicon.ico">
|
<link rel="icon" href="/favicon.ico">
|
||||||
-->
|
-->
|
||||||
</head>
|
</head>
|
||||||
<body>
|
<body>
|
||||||
<div class="container">
|
<div class="container">
|
||||||
<!-- Static navbar -->
|
<!-- Static navbar -->
|
||||||
<nav id="kobalt-navbar" class="navbar navbar-default">
|
<nav id="kobalt-navbar" class="navbar navbar-default">
|
||||||
</nav>
|
</nav>
|
||||||
<!-- Main component for a primary marketing message or call to action -->
|
<!-- Main component for a primary marketing message or call to action -->
|
||||||
<h2>How to write a Kobalt plug-in</h2>
|
<h2>How to write a Kobalt plug-in</h2>
|
||||||
<!-- Main content -->
|
<!-- Main content -->
|
||||||
<div class="col-md-9">
|
<div class="col-md-9">
|
||||||
<h2 class="section" id="tutorial">Tutorial</h2>
|
<h2 class="section" id="tutorial">Tutorial</h2>
|
||||||
<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
|
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
|
<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.
|
and keep reading.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<h2 class="section" id="philosophy">Plug-in architecture</h3>
|
<h2 class="section" id="philosophy">Plug-in architecture</h3>
|
||||||
<p>
|
<p>
|
||||||
<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,
|
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
|
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
|
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
|
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
|
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
|
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".
|
<a href="https://en.wikipedia.org/wiki/Hollywood_principle">"Hollywood Principle"</a>: "Don't call us, we'll call you".
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
These "actors" are exactly what the <code>kobalt-plugin.xml</code> file describes. This file informs Kobalt about
|
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
|
the various ways in which your plug-in participates in the build system by specifying 1) plug-ins, 2) contributors
|
||||||
or 3) interceptors.
|
or 3) interceptors.
|
||||||
</p>
|
</p>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<h3 class="section" id="introduction" indent="1">Parts</h2>
|
<h3 class="section" id="introduction" indent="1">Parts</h2>
|
||||||
<p>
|
<p>
|
||||||
<ul>
|
<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="#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>project</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="#directives"><b>Directives</b></a>. Kotlin functions that users of your plug-in can invoke in their build file, such as <code>project</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="#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>
|
<li><a href="#properties"><b>Properties</b></a>. Plug-ins can export properties and read properties from other plug-ins.</li>
|
||||||
</ul>
|
</ul>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<h3 class="section" id="kobalt-plugin-xml" indent="1">kobalt-plugin.xml</h2>
|
<h3 class="section" id="kobalt-plugin-xml" indent="1">kobalt-plugin.xml</h2>
|
||||||
<p>
|
<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:
|
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>
|
</p>
|
||||||
<pre class="brush:xml">
|
<pre class="brush:xml">
|
||||||
<plugin-actors>
|
<plugin-actors>
|
||||||
<class-name>com.beust.kobalt.plugin.java.JavaPlugin</class-name>
|
<class-name>com.beust.kobalt.plugin.java.JavaPlugin</class-name>
|
||||||
|
|
@ -276,19 +276,19 @@ class JavaBuildGenerator: ITemplateContributor {</pre>
|
||||||
</td>
|
</td>
|
||||||
</tr>
|
</tr>
|
||||||
</table>
|
</table>
|
||||||
<h2 class="section" id="selection-process">Selection process</h2>
|
<h2 class="section" id="selection-process">Selection process</h2>
|
||||||
<p>
|
<p>
|
||||||
Several plug-ins might want to contribute to a specific task where only one participant should be allowed,
|
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
|
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
|
ever be performed by no more than one plug-in for a given project. Therefore, when comes the time to
|
||||||
compile a project,
|
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,
|
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
|
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.
|
<em>affinity</em> to that task for a given project.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Contributors that want to participate in a selection process need to implement the following interface:
|
Contributors that want to participate in a selection process need to implement the following interface:
|
||||||
</p>
|
</p>
|
||||||
<pre class="brush:java">
|
<pre class="brush:java">
|
||||||
interface IProjectAffinity {
|
interface IProjectAffinity {
|
||||||
/**
|
/**
|
||||||
|
|
@ -356,19 +356,19 @@ public fun myConfig(init: Info.() -> Unit) = Info().apply {
|
||||||
(Kobalt.findPlugin("my-plug-in") as MyPlugin).info = info
|
(Kobalt.findPlugin("my-plug-in") as MyPlugin).info = info
|
||||||
this
|
this
|
||||||
}</pre>
|
}</pre>
|
||||||
<p>
|
<p>
|
||||||
Obviously, you can choose any kind of API to communicate between the directive and its plug-in. In the code
|
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
|
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...
|
a function, just set one boolean instead of the whole object, etc...
|
||||||
</p>
|
</p>
|
||||||
<h2 class="section" id="tasks">Tasks</h2>
|
<h2 class="section" id="tasks">Tasks</h2>
|
||||||
<p>
|
<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.
|
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>
|
</p>
|
||||||
<h3 class="section" indent="1">Static tasks</h3>
|
<h3 class="section" indent="1">Static tasks</h3>
|
||||||
<p>
|
<p>
|
||||||
Static tasks are functions declared directly in your plug-in class and annotated with the <code>@Task</code> annotation. Here is an example:
|
Static tasks are functions declared directly in your plug-in class and annotated with the <code>@Task</code> annotation. Here is an example:
|
||||||
</p>
|
</p>
|
||||||
<pre class="brush:java">
|
<pre class="brush:java">
|
||||||
@Task(name = "lineCount", description = "Count the lines", runBefore = arrayOf("compile"))
|
@Task(name = "lineCount", description = "Count the lines", runBefore = arrayOf("compile"))
|
||||||
fun lineCount(project: Project): TaskResult {
|
fun lineCount(project: Project): TaskResult {
|
||||||
|
|
@ -376,96 +376,96 @@ fun lineCount(project: Project): TaskResult {
|
||||||
return TaskResult()
|
return TaskResult()
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
<p>
|
<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.
|
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>
|
||||||
<p>
|
<p>
|
||||||
The <code>@Task</code> annotation accepts the following attributes:
|
The <code>@Task</code> annotation accepts the following attributes:
|
||||||
<dl class="dl-horizontal">
|
<dl class="dl-horizontal">
|
||||||
<dt>name</dt>
|
<dt>name</dt>
|
||||||
<dd>The name of the task, which will be used to invoke it from the command line.</dd>
|
<dd>The name of the task, which will be used to invoke it from the command line.</dd>
|
||||||
<dt>description</dt>
|
<dt>description</dt>
|
||||||
<dd>The description of this command, which will be displayed if the user invokes the usage for the <code>kobaltw</code> command.</dd>
|
<dd>The description of this command, which will be displayed if the user invokes the usage for the <code>kobaltw</code> command.</dd>
|
||||||
<dt>runBefore</dt>
|
<dt>runBefore</dt>
|
||||||
<dd>A list of all the tasks that this task should run prior to.</dd>
|
<dd>A list of all the tasks that this task should run prior to.</dd>
|
||||||
<dt>runAfter</dt>
|
<dt>runAfter</dt>
|
||||||
<dd>A list of all the tasks that should run before this task does.</dd>
|
<dd>A list of all the tasks that should run before this task does.</dd>
|
||||||
<dt>alwaysRunAfter</dt>
|
<dt>alwaysRunAfter</dt>
|
||||||
<dd>A list of all the tasks that will always be run after this task if it's invoked.</dd>
|
<dd>A list of all the tasks that will always be run after this task if it's invoked.</dd>
|
||||||
</dl>
|
</dl>
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
The difference between <code>runAfter</code> and <code>alwaysRunAfter</code> is subtle but important. <code>runAfter</code>
|
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
|
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>
|
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",
|
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>.
|
you say <code>"b runAfter a"</code>.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
For example, <code>compileTest</code> is declared as a <code>runAfter</code> for the task <code>compile</code>.
|
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.
|
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>,
|
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>
|
so a dependency is exactly what we need here: invoking <code>compileTest</code> will trigger <code>compile</code>
|
||||||
but not the other way around.
|
but not the other way around.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
However, there are times where you want to define a task that will <strong>always</strong> run after a given task.
|
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
|
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>
|
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
|
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>.
|
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>
|
Note that there is no <code>alwaysRunBefore</code> annotation since <code>runBefore</code>
|
||||||
achieves the same functionality.
|
achieves the same functionality.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Here are a few different scenarios to illustrate how the three attributes work for the task <code>exampleTask</code>:
|
Here are a few different scenarios to illustrate how the three attributes work for the task <code>exampleTask</code>:
|
||||||
</p>
|
</p>
|
||||||
<p align="center">
|
<p align="center">
|
||||||
<strong>Result of the command <code>./kobaltw --dryRun compile</code></strong>
|
<strong>Result of the command <code>./kobaltw --dryRun compile</code></strong>
|
||||||
</p>
|
</p>
|
||||||
<table width="100%" class="table table-bordered table-condensed">
|
<table width="100%" class="table table-bordered table-condensed">
|
||||||
<thead>
|
<thead>
|
||||||
<td align="center">Configuration for <code>exampleTask</code></td>
|
<td align="center">Configuration for <code>exampleTask</code></td>
|
||||||
<td align="center">Result</td>
|
<td align="center">Result</td>
|
||||||
</thead>
|
</thead>
|
||||||
<tr>
|
<tr>
|
||||||
<td align="center">runBefore = "compile"</td>
|
<td align="center">runBefore = "compile"</td>
|
||||||
<td>
|
<td>
|
||||||
<pre class="brush:plain">kobalt-line-count:clean
|
<pre class="brush:plain">kobalt-line-count:clean
|
||||||
kobalt-line-count:exampleTask
|
kobalt-line-count:exampleTask
|
||||||
kobalt-line-count:compile</pre>
|
kobalt-line-count:compile</pre>
|
||||||
</td>
|
</td>
|
||||||
</tr>
|
</tr>
|
||||||
<tr>
|
<tr>
|
||||||
<td align="center">runAfter = "compile"</td>
|
<td align="center">runAfter = "compile"</td>
|
||||||
<td>
|
<td>
|
||||||
<pre class="brush:plain">kobalt-line-count:clean
|
<pre class="brush:plain">kobalt-line-count:clean
|
||||||
kobalt-line-count:compile</pre>
|
kobalt-line-count:compile</pre>
|
||||||
</td>
|
</td>
|
||||||
</tr>
|
</tr>
|
||||||
<tr>
|
<tr>
|
||||||
<td align="center">alwaysRunAfter = "compile"</td>
|
<td align="center">alwaysRunAfter = "compile"</td>
|
||||||
<td>
|
<td>
|
||||||
<pre class="brush:plain">kobalt-line-count:clean
|
<pre class="brush:plain">kobalt-line-count:clean
|
||||||
kobalt-line-count:compile
|
kobalt-line-count:compile
|
||||||
kobalt-line-count:exampleTask</pre>
|
kobalt-line-count:exampleTask</pre>
|
||||||
</td>
|
</td>
|
||||||
</tr>
|
</tr>
|
||||||
</table>
|
</table>
|
||||||
<h3 class="section" indent="1">Dynamic tasks</h3>
|
<h3 class="section" indent="1">Dynamic tasks</h3>
|
||||||
<p>
|
<p>
|
||||||
Dynamic tasks are useful when you want your plug-in to generate one or several tasks that depend on
|
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>
|
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>
|
annotation on it). Plug-ins declare dynamic tasks by implementing the <code>ITaskContributor</code>
|
||||||
intrface:
|
intrface:
|
||||||
</p>
|
</p>
|
||||||
<pre class="brush:java">
|
<pre class="brush:java">
|
||||||
interface ITaskContributor {
|
interface ITaskContributor {
|
||||||
fun tasksFor(context: KobaltContext) : List<DynamicTask>
|
fun tasksFor(context: KobaltContext) : List<DynamicTask>
|
||||||
}</pre>
|
}</pre>
|
||||||
<p>
|
<p>
|
||||||
For example:
|
For example:
|
||||||
</p>
|
</p>
|
||||||
<pre class="brush:java">
|
<pre class="brush:java">
|
||||||
override fun tasksFor(context: KobaltContext) = listOf(
|
override fun tasksFor(context: KobaltContext) = listOf(
|
||||||
DynamicTask(
|
DynamicTask(
|
||||||
|
|
@ -476,15 +476,15 @@ override fun tasksFor(context: KobaltContext) = listOf(
|
||||||
println("Running dynamicTask")
|
println("Running dynamicTask")
|
||||||
TaskResult()
|
TaskResult()
|
||||||
}))</pre>
|
}))</pre>
|
||||||
<p>
|
<p>
|
||||||
<code>DynamicTask</code> mirrors the <code>@Task</code> attributes: <code>name</code>, <code>description</code> and
|
<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
|
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
|
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>.
|
obeys: it takes a <code>Project</code> parameter and returns a <code>TaskResult</code>.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Once you have implemented <code>ITaskContributor</code>, you can see your dynamic task in the list of tasks and run it directly:
|
Once you have implemented <code>ITaskContributor</code>, you can see your dynamic task in the list of tasks and run it directly:
|
||||||
</p>
|
</p>
|
||||||
<pre class="brush:plain">
|
<pre class="brush:plain">
|
||||||
$ ./kobaltw --tasks
|
$ ./kobaltw --tasks
|
||||||
===== kobalt-line-count =====
|
===== kobalt-line-count =====
|
||||||
|
|
@ -493,32 +493,32 @@ $ ./kobaltw --tasks
|
||||||
$ ./kobaltw dynamicTask
|
$ ./kobaltw dynamicTask
|
||||||
Running dynamictask
|
Running dynamictask
|
||||||
</pre>
|
</pre>
|
||||||
<h2 class="section" id="properties">Properties</h2>
|
<h2 class="section" id="properties">Properties</h2>
|
||||||
<p>
|
<p>
|
||||||
Properties are the mechanism that plug-ins can use to export values and also read values that other
|
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:
|
plug-ins have exported. There are two kinds of properties that plug-ins can manipulate:
|
||||||
</p>
|
</p>
|
||||||
<ul>
|
<ul>
|
||||||
<li><strong>Project properties</strong>: project-specific properties.</li>
|
<li><strong>Project properties</strong>: project-specific properties.</li>
|
||||||
<li><strong>Plug-in properties</strong>: general properties that are applicable to no project
|
<li><strong>Plug-in properties</strong>: general properties that are applicable to no project
|
||||||
in particular.</li>
|
in particular.</li>
|
||||||
</ul>
|
</ul>
|
||||||
<h3 class="section" indent="1" id="project-properties">Project properties</h3>
|
<h3 class="section" indent="1" id="project-properties">Project properties</h3>
|
||||||
<p>
|
<p>
|
||||||
<code>Project</code> instances have a property called <code>projectProperties</code> that is an
|
<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
|
instance of the <code>ProjectProperties</code> class. Plugins can put and get values on this
|
||||||
object in order to store project specific properties.
|
object in order to store project specific properties.
|
||||||
</p>
|
</p>
|
||||||
<pre class="brush:java">
|
<pre class="brush:java">
|
||||||
fun taskAssemble(project: Project) : TaskResult {
|
fun taskAssemble(project: Project) : TaskResult {
|
||||||
project.projectProperties.put(PACKAGES, packages)
|
project.projectProperties.put(PACKAGES, packages)
|
||||||
</pre>
|
</pre>
|
||||||
<h3 class="section" indent="1" id="plugin-properties">Plug-in properties</h3>
|
<h3 class="section" indent="1" id="plugin-properties">Plug-in properties</h3>
|
||||||
<p>
|
<p>
|
||||||
The <code>PluginProperties</code> instance can be found on the <code>KobaltContext</code>
|
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
|
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:
|
class, you can read or write variables into it:
|
||||||
</p>
|
</p>
|
||||||
<pre class="brush:java">
|
<pre class="brush:java">
|
||||||
override fun apply(project: Project, context: KobaltContext) {
|
override fun apply(project: Project, context: KobaltContext) {
|
||||||
// Export a property for other plug-ins to use
|
// Export a property for other plug-ins to use
|
||||||
|
|
@ -527,33 +527,33 @@ override fun apply(project: Project, context: KobaltContext) {
|
||||||
val sourceDir = context.pluginProperties.get("pluginName", "somePluginProperty")
|
val sourceDir = context.pluginProperties.get("pluginName", "somePluginProperty")
|
||||||
}
|
}
|
||||||
</pre>
|
</pre>
|
||||||
<h3 class="section" indent="1" id="documenting-properties">Documenting properties</h3>
|
<h3 class="section" indent="1" id="documenting-properties">Documenting properties</h3>
|
||||||
<p>
|
<p>
|
||||||
Plug-ins that define properties should annotate them with the <code>@ExportedPluginProperty</code> or
|
Plug-ins that define properties should annotate them with the <code>@ExportedPluginProperty</code> or
|
||||||
<code>@ExportedProjectProperty</code>annotation:
|
<code>@ExportedProjectProperty</code>annotation:
|
||||||
</p>
|
</p>
|
||||||
<pre class="brush:java">
|
<pre class="brush:java">
|
||||||
companion object {
|
companion object {
|
||||||
@ExportedProjectProperty
|
@ExportedProjectProperty
|
||||||
const val BUILD_DIR = "buildDir"
|
const val BUILD_DIR = "buildDir"
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
<!-- Table of contents -->
|
<!-- Table of contents -->
|
||||||
<div class="col-md-3" id="table-of-contents">
|
<div class="col-md-3" id="table-of-contents">
|
||||||
</div>
|
</div>
|
||||||
<!-- Bootstrap core JavaScript
|
<!-- Bootstrap core JavaScript
|
||||||
================================================== -->
|
================================================== -->
|
||||||
<!-- Placed at the end of the document so the pages load faster -->
|
<!-- 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="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="../bootstrap/dist/js/bootstrap.min.js"></script>
|
||||||
<script src="../js/kobalt.js"></script>
|
<script src="../js/kobalt.js"></script>
|
||||||
<script>generateKobalt();</script>
|
<script>generateKobalt();</script>
|
||||||
<!--
|
<!--
|
||||||
<script src="../bootstrap/dist/js/docs.min.js"></script>
|
<script src="../bootstrap/dist/js/docs.min.js"></script>
|
||||||
-->
|
-->
|
||||||
<!-- IE10 viewport hack for Surface/desktop Windows 8 bug -->
|
<!-- IE10 viewport hack for Surface/desktop Windows 8 bug -->
|
||||||
<!--
|
<!--
|
||||||
<script src="../../assets/js/ie10-viewport-bug-workaround.js"></script>
|
<script src="../../assets/js/ie10-viewport-bug-workaround.js"></script>
|
||||||
-->
|
-->
|
||||||
</div>
|
</div>
|
||||||
</body>
|
</body>
|
||||||
Loading…
Add table
Add a link
Reference in a new issue