Comparar o Lightbuild com a DSL do Kotlin

Se você já sabe como configurar builds do Android com a DSL do Kotlin, esta página mostra como as configurações comuns da DSL do Kotlin são mapeadas para o Lightbuild.

Os exemplos nesta página usam a DSL do Kotlin e o Plug-in do Android para Gradle (AGP) 9.0 ou mais recente, que inclui suporte integrado ao Kotlin.

Arquivos de build

A tabela a seguir mostra o equivalente do Lightbuild de cada arquivo de build da DSL do Kotlin:

Configurações do projeto

Na DSL do Kotlin, o arquivo settings.gradle.kts define o nome do projeto, os módulos e os repositórios para resolver as dependências:

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

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

No Lightbuild, o arquivo project.lightbuild.yaml define as mesmas configurações:

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

A tabela a seguir compara as configurações de todo o projeto:

Tipo de módulo e plug-ins

Na DSL do Kotlin, você escolhe o tipo de um módulo aplicando um plug-in e aplica outros plug-ins para adicionar recursos como o KSP. No Lightbuild, você define o type do módulo, e o Lightbuild aplica os recursos necessários para sua configuração:

Configurações do Android

Na DSL do Kotlin, as configurações do Android são definidas no bloco android do arquivo build.gradle.kts de um 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"
    }
}

No Lightbuild, você define as mesmas configurações no bloco android do arquivo lightbuild.yaml de um 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"

A tabela a seguir compara essas configurações:

Dependências

Na DSL do Kotlin, declare as dependências no bloco dependencies usando configurações como implementation:

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

No Lightbuild, você lista as dependências do módulo em module e as bibliotecas externas em maven:

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

A DSL do Kotlin usa outras configurações, como api, compileOnly e runtimeOnly, para controlar como um módulo usa uma dependência:

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

No Lightbuild, adicione as configurações compile e runtime à dependência:

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

Para mais informações sobre essas configurações, consulte Configurações de dependência.

A tabela a seguir compara as declarações de dependência comuns:

KSP

Na DSL do Kotlin, aplique o plug-in do KSP e adicione processadores com a configuração 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")
}

No Lightbuild, você adiciona processadores ao bloco kspProcessors, e o Lightbuild aplica o plug-in do KSP automaticamente:

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

Testes

Na DSL do Kotlin, defina o executor de teste de instrumentação em defaultConfig e adicione dependências de teste com as configurações testImplementation e 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")
}

No Lightbuild, você configura testes locais em tests.test e testes de instrumentação em 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 build

Com a DSL do Kotlin, você cria e testa na linha de comando executando tarefas do Gradle com o wrapper do Gradle. Com o Lightbuild, você usa a CLI do Lightbuild.

Para mais informações, consulte Criar o app na linha de comando e Criar projetos do Lightbuild na linha de comando.

Bloqueio de dependências

Com a DSL do Kotlin, o bloqueio de dependências é opcional: você o ativa nos scripts de build e, em seguida, grava arquivos de bloqueio executando um build com a flag --write-locks. No Lightbuild, cada módulo tem um arquivo resolved.deps que registra as dependências resolvidas do módulo, que o Lightbuild gera automaticamente. Assim como nos arquivos de bloqueio do Gradle, faça check-in dos arquivos resolved.deps no controle de versões.

Para bloquear as dependências, por exemplo, em um build de CI, adicione a flag --locked-dependencies a lightbuild resolve ou lightbuild test. Com essa flag, o comando falhará se um arquivo resolved.deps não corresponder às dependências do módulo, em vez de atualizar o arquivo:

lightbuild resolve --locked-dependencies

Recursos não suportados

O Lightbuild não oferece suporte aos seguintes recursos da DSL do Kotlin:

• Catálogos de versões e plug-ins de convenção
• Plug-ins personalizados
• Variações de produtos. Em vez disso, crie um módulo de app separado para cada versão do seu app. Para mais informações, consulte Vários módulos de app.
• Módulos do Kotlin Multiplatform (KMP)
• Resolução de dependências por um servidor proxy

Além disso, um projeto não pode misturar módulos da DSL do Kotlin e do Lightbuild. Para problemas conhecidos, consulte as notas da versão do Lightbuild.