-Both these directives allow you to consider an object of type Project.
+Both these directives create an object of type Project.
A
Once you have at least one project configured, the plug-in lets you invoke the following tasks:
+ Variants let you configure your project to generate different artifacts compiled from different sources depending on the variant you selected.
+
+ A variant is made of at least one of the following two components:
+
+ Product flavors usually contains different source files and different logic (e.g. a "free version" and a "pro version". Build types lead to different archives (e.g. "debug" and "release", with the "release" version being obfuscated). This effect is achieved by defining identical source files in different directories and then letting Kobalt build the correct one. Each product flavor and build type has a name which translates directory into a source directory. For example:
+
+ With these variants defined, you can now add source files in the "
+ If you define at least one variant, new tasks get added to your build:
+
+ For example, if you define two flavors, "pro" and "free", and two build types, "debug" and "release", four tasks will be added that combine these: "proDebug", "proRelease", "freeDebug" and "freeRelease". If you assemble any of these, an artifact named after that combination will be created, e.g. "kobalt-0.273-free-debug.jar".
+
+ If you defined at least one variant defined, a special file called
+ This class contains at least two fields defining the current variant:
+
+ You can add your own custom fields to this file by calling the
+ The generated file will then contain:
+
+ Take a look at the variants example
+ project to see an actual example using variants and
The "application" plug-in lets you run your application directly from Project has two mandatory attributes: name and version. If you are planning to deploy your project to a Maven repository, you also have to specify its group (e.g. com.beust) and artifactId (e.g. kobalt).
@@ -92,7 +92,7 @@ A Project has two mandatory attributes: name and The dependencies for your tests
-Tasks
+Tasks
@@ -106,7 +106,103 @@ Once you have at least one project configured, the plug-in lets you invoke the f
-Application
+Variants
+Note
+ Kobalt's variant system is very similar to Android's build types, so you should already be familiar with these concepts if you have built Android applications. The difference is that Kobalt supports variants in its core, so that all projects (not just Android's) can take advantage of it.
+
+
+
+productFlavor("free") {
+}
+
+buildType("release") {
+}
+ src/free/java" and "src/release/java" directories (Kotlin is also supported):
+
+src/free/java/Product.java
+src/release/java/Product.java
+
+$ ./kobaltw --tasks
+
+===== java =====
+compileFreeRelease
+compileFreeDebug
+
+===== packaging =====
+assembleFreeRelease
+assembleFreeDebug
+ BuildConfig
+ BuildConfig.java (or
+ BuildConfig.kt) will be automatically generated.
+ Note
+ You need to define packageName in your project in order for this file to be generated or
+ Kobalt will fail.
+
+class BuildConfig {
+ companion object {
+ val PRODUCT_FLAVOR : String = "pro"
+ val BUILD_TYPE : String = "debug"
+ }
+}
+ buildConfig directive
+ inside your
+ flavor:
+
+productFlavor("free") {
+ buildConfig {
+ field("aStringField", "String", "\"The free field\"")
+ field("anIntField", "Int", "42")
+ }
+}
+
+class BuildConfig {
+ companion object {
+ val PRODUCT_FLAVOR : String = "free"
+ val BUILD_TYPE : String = "debug"
+ val aStringField : String = "The free field"
+ val anIntField : Int = 42
+ }
+}
+BuildConfig.
+Application
kobaltw. You configure
it as follows: