Comparer Lightbuild et le DSL Kotlin

Si vous savez déjà configurer des builds Android avec le DSL Kotlin, cette page vous montre comment les configurations DSL Kotlin courantes sont mappées à Lightbuild.

Les exemples de cette page utilisent le DSL Kotlin et le plug-in Android Gradle (AGP) 9.0 ou version ultérieure, qui inclut la compatibilité intégrée avec Kotlin.

Fichiers de compilation

Le tableau suivant présente l'équivalent Lightbuild de chaque fichier de compilation DSL Kotlin :

Paramètres du projet

Dans le DSL Kotlin, le fichier settings.gradle.kts définit le nom du projet, ses modules et les dépôts à partir desquels résoudre les dépendances :

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

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

Dans Lightbuild, le fichier project.lightbuild.yaml définit les mêmes paramètres :

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

Le tableau suivant compare les paramètres à l'échelle du projet :

Type de module et plug-ins

Dans le DSL Kotlin, vous choisissez le type d'un module en appliquant un plug-in, et vous appliquez d'autres plug-ins pour ajouter des fonctionnalités telles que KSP. Dans Lightbuild, vous définissez le type du module, et Lightbuild applique les fonctionnalités dont votre configuration a besoin :

Paramètres Android

Dans le DSL Kotlin, vous configurez les paramètres Android dans le bloc android du fichier build.gradle.kts d'un module :

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

Dans Lightbuild, vous configurez les mêmes paramètres dans le bloc android du fichier lightbuild.yaml d'un module :

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"

Le tableau suivant compare ces paramètres :

Dépendances

Dans le DSL Kotlin, vous déclarez les dépendances dans le bloc dependencies, à l'aide de configurations telles que implementation :

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

Dans Lightbuild, vous listez les dépendances de module sous module et les bibliothèques externes sous maven :

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

Le DSL Kotlin utilise d'autres configurations, telles que api, compileOnly et runtimeOnly, pour contrôler la façon dont un module utilise une dépendance :

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

Dans Lightbuild, vous ajoutez plutôt les paramètres compile et runtime à la dépendance :

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

Pour en savoir plus sur ces paramètres, consultez Paramètres de dépendance.

Le tableau suivant compare les déclarations de dépendances courantes :

KSP

Dans le DSL Kotlin, vous appliquez le plug-in KSP et ajoutez des processeurs avec la configuration 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")
}

Dans Lightbuild, vous ajoutez des processeurs au bloc kspProcessors, et Lightbuild applique automatiquement le plug-in KSP :

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

Dans le DSL Kotlin, vous définissez l'exécuteur de test d'instrumentation dans defaultConfig et vous ajoutez des dépendances de test avec les configurations testImplementation et 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")
}

Dans Lightbuild, vous configurez les tests locaux dans tests.test et les tests d'instrumentation dans 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

Commandes de compilation

Avec le DSL Kotlin, vous compilez et testez votre application à partir de la ligne de commande en exécutant des tâches Gradle avec le wrapper Gradle. Avec Lightbuild, vous utilisez la CLI Lightbuild.

Pour en savoir plus, consultez Créer une application à partir de la ligne de commande et Créer des projets Lightbuild à partir de la ligne de commande.

Verrouillage des dépendances

Avec le DSL Kotlin, le verrouillage des dépendances est facultatif : vous l'activez dans vos scripts de compilation, puis vous écrivez des fichiers de verrouillage en exécutant une compilation avec l'option --write-locks. Dans Lightbuild, chaque module possède un fichier resolved.deps qui enregistre les dépendances résolues du module, que Lightbuild génère automatiquement. Comme pour les fichiers de verrouillage Gradle, archivez vos fichiers resolved.deps dans le contrôle des versions.

Pour verrouiller vos dépendances, par exemple dans un build d'intégration continue, ajoutez l'option --locked-dependencies à lightbuild resolve ou lightbuild test. Avec cette option, la commande échoue si un fichier resolved.deps ne correspond pas aux dépendances du module, au lieu de mettre à jour le fichier :

lightbuild resolve --locked-dependencies

Fonctionnalités non compatibles

Lightbuild n'est pas compatible avec les fonctionnalités DSL Kotlin suivantes :

• Catalogues de versions et plug-ins de convention
• Plug-ins personnalisés
• Types de produit. Créez plutôt un module d'application distinct pour chaque version de votre application. Pour en savoir plus, consultez Plusieurs modules d'application.
• Modules Kotlin Multiplatform (KMP)
• Résolution des dépendances via un serveur proxy

De plus, un projet ne peut pas combiner des modules DSL Kotlin et Lightbuild. Pour connaître les problèmes connus, consultez les notes de version de Lightbuild.