Groovy och Gradle: JVM-automatisering och byggsystemutveckling · Lektion

Beroenden mellan projekt

Hantera beroenden mellan delprojekt och säkerställ korrekt byggordning och artefaktupplösning.

Lektion 3 av 411 steg

Beroenden mellan projekt är en gratis lektion i Groovy och Gradle: JVM-automatisering och byggsystemutveckling på CoddyKit. Detta är lektion 3 av 4. Ni kan läsa hela lektionen gratis nedan och sedan öva praktiskt i webbläsaren med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt. Den ingår i lärvägen för Groovy och Gradle: JVM-automatisering och byggsystemutveckling, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Groovy och Gradle: JVM-automatisering och byggsystemutveckling innehåller totalt 4 lektioner.

Introduktion till projektberoenden

I ett Gradle-bygge med flera projekt behöver olika delprojekt ofta samarbeta. Ett delprojekt kan till exempel producera ett bibliotek som ett annat delprojekt använder.

Det är här beroenden mellan projekt kommer in! De definierar hur delprojekt är beroende av varandra och säkerställer rätt byggordning samt delning av artefakter.

  • Beroenden mellan projekt: Hur ett delprojekt använder kod eller utdata från ett annat delprojekt.
  • Avgörande för modulära applikationer.

Deklarera ett grundläggande beroende

Det är enkelt att deklarera att ett delprojekt är beroende av ett annat i Gradle. Du använder funktionen project() i blocket dependencies.

Om ditt app-delprojekt till exempel behöver kod från ditt lib-delprojekt lägger du till följande i app/build.gradle:

// app/build.gradle
dependencies {
    implementation project(':lib')
}

Delen :lib syftar på sökvägen till delprojektet lib i förhållande till roten.

Konfigurera vårt exempel

Föreställ dig en enkel konfiguration med flera projekt. Vi har ett rotprojekt, ett app-delprojekt och ett lib-delprojekt.

Din settings.gradle skulle se ut så här:

// settings.gradle
rootProject.name = 'my-multi-project'
include 'app', 'lib'

Detta talar om för Gradle att våra två delprojekt är app och lib.

`implementation` jämfört med `api`

När du deklarerar beroenden mellan projekt använder du vanligtvis konfigurationer som implementation eller api.

  • implementation: Det vanligaste valet. Beroendet används internt av delprojektet och exponeras inte för dem som använder delprojektet.
  • api: Exponerar beroendet för användare. Om app är beroende av lib via api och otherApp är beroende av app, kommer otherApp också att se API:t i lib.

För intern användning mellan delprojekt föredras vanligtvis implementation, eftersom det ger bättre inkapsling och snabbare byggen.

Biblioteksdelprojektet (`lib`)

Först skapar vi en enkel klass i vårt lib-delprojekt som app-delprojektet ska använda. Klassen tillhandahåller ett grundläggande hjälpverktyg.

I lib/src/main/groovy/com/coddykit/LibUtils.groovy:

package com.coddykit

class LibUtils {
    static String getGreeting() {
        return "Hello from LibUtils!"
    }
}

App-delprojektet använder kod från `lib`

Nu låter vi vårt app-delprojekt använda klassen LibUtils från vårt lib-delprojekt. Kom ihåg att vi deklarerade implementation project(':lib') i app/build.gradle.

Försök köra det här exemplet:

package com.coddykit

import com.coddykit.LibUtils

class AppMain {
    static void main(String[] args) {
        String message = LibUtils.getGreeting()
        System.out.println(message)
    }
}

Automatisk byggordning

En av de största fördelarna med att deklarera beroenden mellan projekt är att Gradle automatiskt räknar ut rätt byggordning.

  • Om app är beroende av lib ser Gradle till att lib kompileras och att dess artefakter är tillgängliga innan app börjar kompileras.
  • Det gör att du slipper hantera byggsekvenser manuellt, särskilt i komplexa konfigurationer med flera projekt.

När du kör gradle build från roten bygger Gradle först lib och därefter app.

Förstå transitiva effekter

Vad händer om ditt lib-delprojekt självt är beroende av ett annat delprojekt, exempelvis common?

// lib/build.gradle
dependencies {
    implementation project(':common')
}

// app/build.gradle
dependencies {
    implementation project(':lib')
}

Om app är beroende av lib och lib är beroende av common ser Gradle till att common också byggs och att dess artefakter transitivt är tillgängliga på apps classpath vid kompilering, men inte nödvändigtvis i dess API om implementation används för lib.

Håll beroendena rena

Följ dessa rekommenderade metoder för att hålla dina flerprojektsbyggen hanterbara och effektiva:

  • Minimala beroenden: Deklarera bara beroenden till de delprojekt du verkligen behöver.
  • Använd implementation: Föredra implementation framför api för interna delprojektberoenden, så att inkapslingen förbättras och färre ombyggen krävs.
  • Tydliga gränser: Utforma dina delprojekt med tydliga ansvarsområden för att undvika cirkulära beroenden.
  • Undvik djupa sökvägar: Håll delprojektens sökvägar korta (till exempel är :module:submodule bra, men undvik onödigt långa sökvägar).

Kontroll av beroendedeklaration

Du har ett flerprojektsbygge med ett web-delprojekt och ett core-delprojekt. web-delprojektet behöver använda klasser från core-delprojektet i sin interna logik, men får inte exponera cores API för ytterligare användare av web.

Sammanfattning av beroenden mellan projekt

Bra jobbat! I den här lektionen har du lärt dig att hantera beroenden mellan delprojekt i ett Gradle-bygge med flera projekt.

  • Vi gick igenom hur du deklarerar beroenden med project(':subproject').
  • Vi diskuterade varför implementation är viktigt för intern användning.
  • Du såg hur Gradle automatiskt hanterar byggordningen.
  • Vi utforskade rekommenderade metoder för ren beroendehantering.

Att behärska beroenden mellan projekt är avgörande för att effektivt bygga stora, modulära applikationer med Gradle!

Gratis att börja

Lär dig Groovy med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser
12
Lektioner
48

Vanliga frågor

Är lektionen ”Beroenden mellan projekt” gratis?

Ja – hela texten till ”Beroenden mellan projekt” kan läsas gratis här på webben. Om Ni vill öva interaktivt med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt och låsa upp resten av kursen i Groovy och Gradle: JVM-automatisering och byggsystemutveckling, kan Ni uppgradera till CoddyKit PRO. Kursen i Groovy och Gradle: JVM-automatisering och byggsystemutveckling innehåller totalt 4 lektioner.

Vad lär jag mig i ”Beroenden mellan projekt”?

Hantera beroenden mellan delprojekt och säkerställ korrekt byggordning och artefaktupplösning. Ni övar på Groovy och Gradle: JVM-automatisering och byggsystemutveckling med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Groovy och Gradle: JVM-automatisering och byggsystemutveckling?

Du behöver inga förkunskaper. Utbildningen i Groovy och Gradle: JVM-automatisering och byggsystemutveckling på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 3 av 4.

Hur lång tid tar lektionen ”Beroenden mellan projekt”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Groovy och Gradle: JVM-automatisering och byggsystemutveckling-lektionen?

Ja. Varje Groovy och Gradle: JVM-automatisering och byggsystemutveckling-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

  1. Monorepo-projektstruktur
  2. Delprojekt och konfigurationer
  3. Beroenden mellan projekt
  4. Kompositbyggen och byggkomposition
← Tillbaka till Groovy och Gradle: JVM-automatisering och byggsystemutveckling