+ Profiles allow you to run altered versions of your build file by using command + line parameters. +
+
+ You start by defining boolean values initialized to false in your build file:
+
+ val experimental = false + val premium = false ++
+ Then you use this variable wherever you need it in your build file: +
+
+ val p = javaProject {
+ name = if (experimental) "project-exp" else "project"
+ version = "1.3"
+
+
+ Finally, you invoke ./kobaltw with the --profiles parameter followed by the profiles you want to activate, separated by a comma:
+
+ ./kobaltw -profiles experimental,premium assemble ++
+ Keep in mind that since your build file is a real Kotlin source file, + you can use these profile variables pretty much anywhere, e.g.: +
dependencies {
- compile("com.beust:kobalt:0.61")
-}
-
-
-
- packaging {
- jar {
- manifest {
- attributes("Kobalt-Plugin-Class", "com.beust.kobalt.example.ExamplePlugin")
- }
- }
-
-
-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, context: KobaltContext) {
- println("Applying plugin ${name} with project ${project}")
- }
-}
-
-
-
-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()
-}
-
-
-TaskResult object, which can be initialized with false if the task didn't succeed for some reason.
- kobaltw command (e.g. "./kobaltw coverage")
- "./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.
--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")
-}
+ if (experimental)
+ "com.squareup.okhttp:okhttp:2.4.0"
+ else
+ "com.squareup.okhttp:okhttp:2.5.0",