Porównanie Lightbuild z Kotlin DSL

Jeśli wiesz, jak konfigurować kompilacje Androida za pomocą Kotlin DSL, na tej stronie dowiesz się, jak typowe konfiguracje Kotlin DSL są mapowane na Lightbuild.

Przykłady na tej stronie używają języka Kotlin DSL i wtyczki Androida do obsługi Gradle (AGP) w wersji 9.0 lub nowszej, która zawiera wbudowaną obsługę języka Kotlin.

Pliki kompilacji

W tabeli poniżej znajdziesz odpowiedniki plików kompilacji DSL w Kotlin w Lightbuild:

Ustawienia projektu

W Kotlin DSL plik settings.gradle.kts definiuje nazwę projektu, jego moduły i repozytoria, z których mają być rozwiązywane zależności:

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

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

W Lightbuild plik project.lightbuild.yaml definiuje te same ustawienia:

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

Tabela poniżej zawiera porównanie ustawień dla całego projektu:

Typ modułu i wtyczki

W języku DSL Kotlina typ modułu wybiera się przez zastosowanie wtyczki, a inne wtyczki stosuje się, aby dodać funkcje takie jak KSP. W Lightbuild ustawiasz type modułu, a Lightbuild stosuje funkcje, których wymaga Twoja konfiguracja:

Ustawienia Androida

W Kotlin DSL ustawienia Androida konfiguruje się w bloku android pliku build.gradle.kts modułu:

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

W Lightbuild te same ustawienia konfigurujesz w bloku android pliku lightbuild.yaml modułu:

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"

W tabeli poniżej znajdziesz porównanie tych ustawień:

Zależności

W Kotlin DSL deklarujesz zależności w bloku dependencies, używając konfiguracji takich jak implementation:

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

W Lightbuild zależności modułów są wymienione w sekcji module, a biblioteki zewnętrzne w sekcji maven:

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

Kotlin DSL używa innych konfiguracji, takich jak api, compileOnly i runtimeOnly, aby kontrolować, jak moduł używa zależności:

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

W Lightbuild ustawienia compile i runtime dodajesz do zależności:

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

Więcej informacji o tych ustawieniach znajdziesz w artykule Ustawienia zależności.

W tabeli poniżej znajdziesz porównanie typowych deklaracji zależności:

kluczowa cecha produktu

W Kotlin DSL stosujesz wtyczkę KSP i dodajesz procesory za pomocą konfiguracji 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")
}

W Lightbuild dodajesz procesory do bloku kspProcessors, a Lightbuild automatycznie stosuje wtyczkę 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

Testy

W języku DSL Kotlin ustawiasz moduł uruchamiający testy z instrumentacją w pliku defaultConfig i dodajesz zależności testowe za pomocą konfiguracji testImplementation i 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")
}

W Lightbuild testy lokalne konfigurujesz w pliku tests.test, a testy z instrumentacją w pliku 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

Polecenia kompilacji

W przypadku Kotlin DSL kompilujesz i testujesz z poziomu wiersza poleceń, uruchamiając zadania Gradle za pomocą Gradle Wrappera. W przypadku Lightbuild używasz interfejsu wiersza poleceń Lightbuild.

Więcej informacji znajdziesz w artykułach o kompilowaniu aplikacji z poziomu wiersza poleceń i kompilowaniu projektów Lightbuild z poziomu wiersza poleceń.

Blokowanie zależności

W przypadku Kotlin DSL blokowanie zależności jest opcjonalne: włączasz je w skryptach kompilacji, a następnie zapisujesz pliki blokady, uruchamiając kompilację z flagą --write-locks. W Lightbuild każdy moduł ma plik resolved.deps, który rejestruje rozwiązane zależności modułu i jest generowany automatycznie przez Lightbuild. Podobnie jak w przypadku plików blokady Gradle, pliki resolved.deps należy przekazać do systemu kontroli wersji.

Aby zablokować zależności, na przykład w kompilacji CI, dodaj flagę --locked-dependencies do lightbuild resolve lub lightbuild test. Jeśli użyjesz tej flagi, polecenie nie powiedzie się, gdy plik resolved.deps nie będzie zgodny z zależnościami modułu, zamiast aktualizować plik:

lightbuild resolve --locked-dependencies

Nieobsługiwane funkcje

Lightbuild nie obsługuje tych funkcji Kotlin DSL:

• Katalogi wersji i wtyczki konwencji
• Wtyczki niestandardowe
• Warianty usługi. Zamiast tego utwórz osobny moduł aplikacji dla każdej wersji aplikacji. Więcej informacji znajdziesz w artykule Wiele modułów aplikacji.
• Moduły Kotlin Multiplatform (KMP)
• Rozwiązywanie zależności przez serwer proxy

Ponadto projekt nie może zawierać jednocześnie modułów Kotlin DSL i Lightbuild. Znane problemy znajdziesz w informacjach o wersji Lightbuild.