השוואה בין Lightbuild ל-Kotlin DSL

אם אתם יודעים איך להגדיר גרסאות build של Android באמצעות Kotlin DSL, בדף הזה מוסבר איך להמיר הגדרות נפוצות של Kotlin DSL ל-Lightbuild.

הדוגמאות בדף הזה משתמשות ב-Kotlin DSL ובפלאגין של Android Gradle‏ (AGP) מגרסה 9.0 ואילך, שכולל תמיכה מובנית ב-Kotlin.

קבצי build

בטבלה הבאה מוצג קובץ ה-build המקביל ב-Lightbuild לכל קובץ build ב-Kotlin DSL:

הגדרות הפרויקט

ב-Kotlin DSL, הקובץ settings.gradle.kts מגדיר את שם הפרויקט, את המודולים שלו ואת המאגרים שמהם נפתרים יחסי התלות:

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

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

ב-Lightbuild, הקובץ project.lightbuild.yaml מגדיר את אותן הגדרות:

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

בטבלה הבאה מוצגת השוואה בין ההגדרות ברמת הפרויקט:

סוג המודול והפלאגינים

ב-Kotlin DSL, בוחרים את סוג המודול על ידי החלת פלאגין, ומחילים פלאגינים אחרים כדי להוסיף תכונות כמו KSP. ב-Lightbuild, מגדירים את ה-type של המודול, ו-Lightbuild מחיל את התכונות שנדרשות להגדרה:

הגדרות Android

ב-Kotlin DSL, מגדירים את הגדרות Android בבלוק android של קובץ build.gradle.kts של מודול:

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

ב-Lightbuild, קובעים את אותן הגדרות בבלוק android של קובץ lightbuild.yaml של מודול:

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"

בטבלה הבאה מוצגת השוואה בין ההגדרות האלה:

פניות קשורות

ב-Kotlin DSL, מצהירים על יחסי תלות בבלוק dependencies, באמצעות הגדרות כמו implementation:

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

ב-Lightbuild, מפרטים את יחסי התלות של המודולים בקטע module, ואת הספריות החיצוניות בקטע maven:

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

Kotlin DSL משתמש בהגדרות אחרות, כמו api,‏ compileOnly ו-runtimeOnly, כדי לקבוע איך מודול משתמש ביחסי תלות:

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

ב-Lightbuild, מוסיפים את ההגדרות compile ו-runtime ליחסי התלות:

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

מידע נוסף על ההגדרות האלה מופיע במאמר הגדרות של יחסי תלות.

בטבלה הבאה מוצגת השוואה בין הצהרות נפוצות על יחסי תלות:

KSP

ב-Kotlin DSL, מחילים את הפלאגין של KSP ומוסיפים מעבדים באמצעות ההגדרה 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")
}

ב-Lightbuild, מוסיפים מעבדים לבלוק kspProcessors, ו-Lightbuild מחיל את הפלאגין של 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

בדיקות

ב-Kotlin DSL, מגדירים את כלי ההרצה של בדיקות האינסטרומנטציה ב-defaultConfig, ומוסיפים יחסי תלות של בדיקות באמצעות ההגדרות האישיות של testImplementation ו-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")
}

ב-Lightbuild, מגדירים בדיקות מקומיות ב-tests.test ובדיקות אינסטרומנטציה ב-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

ב-Kotlin DSL, אתם יוצרים ובודקים משורת הפקודה על ידי הפעלת משימות Gradle באמצעות Gradle wrapper. ב-Lightbuild משתמשים ב-Lightbuild CLI.

מידע נוסף זמין במאמרים פיתוח האפליקציה משורת הפקודה ופיתוח פרויקטים של Lightbuild משורת הפקודה.

נעילת תלויות

ב-Kotlin DSL, נעילת יחסי תלות היא אופציונלית: מפעילים אותה בסקריפטים של ה-build, ואז כותבים קובצי נעילה על ידי הפעלת build עם הדגל --write-locks. ב-Lightbuild, לכל מודול יש קובץ resolved.deps שמתעד את יחסי התלות שנפתרו במודול, ו-Lightbuild יוצר אותו באופן אוטומטי. כמו בקובצי הנעילה של Gradle, צריך להוסיף את קובצי ה-resolved.deps לניהול הגרסאות.

כדי לנעול את יחסי התלות, למשל ב-build של CI, מוסיפים את הדגל --locked-dependencies ל-lightbuild resolve או ל-lightbuild test. עם הדגל הזה, הפקודה נכשלת אם קובץ resolved.deps לא תואם ליחסי התלות של המודול, במקום לעדכן את הקובץ:

lightbuild resolve --locked-dependencies

תכונות שאינן נתמכות

‫Lightbuild לא תומך בתכונות הבאות של Kotlin DSL:

• קטלוגים של גרסאות ויישומי פלאגין של מוסכמות
• פלאגינים בהתאמה אישית
• גרסאות המוצרים. במקום זאת, צרו מודול אפליקציה נפרד לכל גרסה של האפליקציה. מידע נוסף זמין בקטע מודולים מרובים של אפליקציות.
• מודולים של Kotlin Multiplatform‏ (KMP)
• פתרון תלות באמצעות שרת proxy

בנוסף, אי אפשר לשלב בפרויקט מודולים של Kotlin DSL ו-Lightbuild. בעיות מוכרות מפורטות בנתוני הגרסה של Lightbuild.