Compare Lightbuild with Kotlin DSL

If you're familiar with configuring Android builds with Kotlin DSL, this page shows how common Kotlin DSL configurations map to Lightbuild.

The examples on this page use Kotlin DSL and Android Gradle plugin (AGP) 9.0 or higher, which includes built-in Kotlin support.

Build files

The following table shows the Lightbuild equivalent of each Kotlin DSL build file:

Project settings

In Kotlin DSL, the settings.gradle.kts file defines the project's name, its modules, and the repositories to resolve dependencies from:

dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
    }
}

rootProject.name = "MyApp"
include(":app")
include(":app-core")

In Lightbuild, the project.lightbuild.yaml file defines the same settings:

project:
  name: MyApp
modules:
  - app
  - app-core
repositories:
  - google
  - mavenCentral

The following table compares project-wide settings:

Module type and plugins

In Kotlin DSL, you choose a module's type by applying a plugin, and you apply other plugins to add features such as KSP. In Lightbuild, you set the module's type, and Lightbuild applies the features that your configuration needs:

Android settings

In Kotlin DSL, you configure Android settings in the android block of a module's build.gradle.kts file:

plugins {
    id("com.android.application")
}

android {
    namespace = "com.example.myapp.app"
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 24
        targetSdk = 36
        versionCode = 1
        versionName = "1.0"
    }
}

In Lightbuild, you configure the same settings in the android block of a module's lightbuild.yaml file:

platform: android
type: application
android:
  namespace: com.example.myapp.app
  compileSdk:
    version:
      release:
        apiLevel: 36
  minSdk:
    version:
      release:
        apiLevel: 24
  targetSdk:
    version:
      release:
        apiLevel: 36
  applicationId: com.example.myapp
  versionCode: 1
  versionName: "1.0"

The following table compares these settings:

Dependencies

In Kotlin DSL, you declare dependencies in the dependencies block, using configurations such as implementation:

dependencies {
    implementation(project(":app-core"))
    implementation("androidx.core:core-ktx:1.18.0")
}

In Lightbuild, you list module dependencies under module, and external libraries under maven:

android:
  dependencies:
    module:
      - //app-core
    maven:
      - androidx.core:core-ktx:1.18.0

Kotlin DSL uses other configurations, such as api, compileOnly, and runtimeOnly, to control how a module uses a dependency:

dependencies {
    api(project(":data"))
    compileOnly("androidx.annotation:annotation:1.9.1")
}

In Lightbuild, you add compile and runtime settings to the dependency instead:

android:
  dependencies:
    module:
      - //data:
          compile: public
    maven:
      - androidx.annotation:annotation:1.9.1:
          runtime: off

For more information about these settings, see Dependency settings.

The following table compares common dependency declarations:

KSP

In Kotlin DSL, you apply the KSP plugin and add processors with the ksp configuration:

plugins {
    id("com.android.library")
    id("com.google.devtools.ksp")
}

dependencies {
    implementation("com.squareup.moshi:moshi:1.15.2")
    implementation("com.squareup.moshi:moshi-kotlin:1.15.2")
    ksp("com.squareup.moshi:moshi-kotlin-codegen:1.15.2")
}

In Lightbuild, you add processors to the kspProcessors block, and Lightbuild applies the KSP plugin automatically:

type: library
android:
  dependencies:
    maven:
      - com.squareup.moshi:moshi:1.15.2
      - com.squareup.moshi:moshi-kotlin:1.15.2
  kspProcessors:
    maven:
      - com.squareup.moshi:moshi-kotlin-codegen:1.15.2

Tests

In Kotlin DSL, you set the instrumentation test runner in defaultConfig, and you add test dependencies with the testImplementation and androidTestImplementation configurations:

android {
    defaultConfig {
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
    }
}

dependencies {
    testImplementation("junit:junit:4.13.2")
    androidTestImplementation("androidx.test.ext:junit:1.3.0")
    androidTestImplementation("androidx.test.espresso:espresso-core:3.7.0")
}

In Lightbuild, you configure local tests in tests.test and instrumented tests in tests.androidTest:

android:
  tests:
    test:
      dependencies:
        maven:
          - junit:junit:4.13.2
    androidTest:
      runner: androidx.test.runner.AndroidJUnitRunner
      dependencies:
        maven:
          - androidx.test.ext:junit:1.3.0
          - androidx.test.espresso:espresso-core:3.7.0

Build commands

With Kotlin DSL, you build and test from the command line by running Gradle tasks with the Gradle wrapper. With Lightbuild, you use the Lightbuild CLI.

For more information, see Build your app from the command line and Build Lightbuild projects from the command line.

Dependency locking

With Kotlin DSL, dependency locking is optional: you turn it on in your build scripts, and then write lockfiles by running a build with the --write-locks flag. In Lightbuild, every module has a resolved.deps file that records the module's resolved dependencies, which Lightbuild generates automatically. As with Gradle lockfiles, check in your resolved.deps files to version control.

To lock your dependencies, for example in a CI build, add the --locked-dependencies flag to lightbuild resolve or lightbuild test. With this flag, the command fails if a resolved.deps file doesn't match the module's dependencies, instead of updating the file:

lightbuild resolve --locked-dependencies

Unsupported features

Lightbuild doesn't support the following Kotlin DSL features:

• Version catalogs and convention plugins
• Custom plugins
• Product flavors. Instead, create a separate app module for each version of your app. For more information, see Multiple app modules.
• Kotlin Multiplatform (KMP) modules
• Dependency resolution through a proxy server

In addition, a project can't mix Kotlin DSL and Lightbuild modules. For known issues, see the Lightbuild release notes.