Compara Lightbuild con el DSL de Kotlin

Si conoces la configuración de compilaciones de Android con el DSL de Kotlin, en esta página se muestra cómo se asignan las configuraciones comunes del DSL de Kotlin a Lightbuild.

En los ejemplos de esta página, se usan el DSL de Kotlin y el complemento de Android para Gradle (AGP) 9.0 o una versión posterior, que incluye compatibilidad integrada con Kotlin.

Archivos de compilación

En la siguiente tabla, se muestra el equivalente de Lightbuild de cada archivo de compilación de DSL de Kotlin:

Configuración del proyecto

En el DSL de Kotlin, el archivo settings.gradle.kts define el nombre del proyecto, sus módulos y los repositorios de los que se resolverán las dependencias:

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

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

En Lightbuild, el archivo project.lightbuild.yaml define la misma configuración:

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

En la siguiente tabla, se comparan los parámetros de configuración de todo el proyecto:

Tipo de módulo y complementos

En el DSL de Kotlin, eliges el tipo de módulo aplicando un complemento y aplicas otros complementos para agregar funciones, como KSP. En Lightbuild, estableces el type del módulo y Lightbuild aplica las funciones que necesita tu configuración:

Configuración de Android

En el DSL de Kotlin, estableces la configuración de Android en el bloque android del archivo build.gradle.kts de un módulo:

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"
    }
}

En Lightbuild, estableces los mismos parámetros de configuración en el bloque android del archivo lightbuild.yaml de un módulo:

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"

En la siguiente tabla, se comparan estos parámetros de configuración:

Dependencias

En el DSL de Kotlin, declaras dependencias en el bloque dependencies con parámetros de configuración como implementation:

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

En Lightbuild, las dependencias de módulos se enumeran en module y las bibliotecas externas, en maven:

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

El DSL de Kotlin usa otras configuraciones, como api, compileOnly y runtimeOnly, para controlar cómo un módulo usa una dependencia:

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

En Lightbuild, en su lugar, agregas los parámetros de configuración compile y runtime a la dependencia:

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

Para obtener más información sobre estos parámetros de configuración, consulta Configuración de dependencias.

En la siguiente tabla, se comparan las declaraciones de dependencia comunes:

argumento de venta clave

En el DSL de Kotlin, aplicas el complemento de KSP y agregas procesadores con la configuración ksp:

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")
}

En Lightbuild, agregas procesadores al bloque kspProcessors, y Lightbuild aplica el complemento de KSP automáticamente:

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

Pruebas

En el DSL de Kotlin, configuras el ejecutor de pruebas de instrumentación en defaultConfig y agregas dependencias de prueba con las configuraciones testImplementation y androidTestImplementation:

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")
}

En Lightbuild, configuras las pruebas locales en tests.test y las pruebas de instrumentación en 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

Comandos de compilación

Con el DSL de Kotlin, compilas y pruebas desde la línea de comandos ejecutando tareas de Gradle con el wrapper de Gradle. Con Lightbuild, usas la CLI de Lightbuild.

Para obtener más información, consulta Cómo compilar tu app desde la línea de comandos y Cómo compilar proyectos de Lightbuild desde la línea de comandos.

Bloqueo de dependencias

Con el DSL de Kotlin, el bloqueo de dependencias es opcional: lo activas en tus secuencias de comandos de compilación y, luego, escribes archivos de bloqueo ejecutando una compilación con la marca --write-locks. En Lightbuild, cada módulo tiene un archivo resolved.deps que registra las dependencias resueltas del módulo, que Lightbuild genera automáticamente. Al igual que con los archivos de bloqueo de Gradle, registra tus archivos resolved.deps en el control de versiones.

Para bloquear tus dependencias, por ejemplo, en una compilación de CI, agrega la marca --locked-dependencies a lightbuild resolve o lightbuild test. Con esta marca, el comando falla si un archivo resolved.deps no coincide con las dependencias del módulo, en lugar de actualizar el archivo:

lightbuild resolve --locked-dependencies

Características no compatibles

Lightbuild no admite las siguientes funciones de DSL de Kotlin:

• Catálogos de versiones y complementos de convenciones
• Complementos personalizados
• Variantes de productos En su lugar, crea un módulo de app independiente para cada versión de tu app. Para obtener más información, consulta Varios módulos de app.
• Módulos de Kotlin Multiplatform (KMP)
• Resolución de dependencias a través de un servidor proxy

Además, un proyecto no puede mezclar módulos de DSL de Kotlin y Lightbuild. Para conocer los problemas conocidos, consulta las notas de la versión de Lightbuild.