Abhängigkeiten zwischen Projekten
Verwalten Sie Abhängigkeiten zwischen Teilprojekten und stellen Sie die korrekte Build-Reihenfolge sowie die Artefaktauflösung sicher.
Abhängigkeiten zwischen Projekten ist eine kostenlose Groovy & Gradle: JVM Automation and Build Engineering-Lektion auf CoddyKit. Dies ist Lektion 3 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Groovy & Gradle: JVM Automation and Build Engineering-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Groovy & Gradle: JVM Automation and Build Engineering-Kurs umfasst insgesamt 4 Lektionen.
Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.
Introduction to Project Dependencies
In a multi-project Gradle build, different subprojects often need to work together. One subproject might produce a library that another subproject uses.
This is where inter-project dependencies come in! They define how subprojects rely on each other, ensuring the correct build order and artifact sharing.
- Inter-project dependencies: How one subproject uses code or outputs from another subproject.
- Crucial for modular applications.
Declaring a Basic Dependency
Declaring that one subproject depends on another is straightforward in Gradle. You use the project() function within your dependencies block.
For example, if your app subproject needs code from your lib subproject, you'd add this to app/build.gradle:
// app/build.gradle
dependencies {
implementation project(':lib')
}The :lib part refers to the path of the lib subproject relative to the root.
Setting Up Our Example
Let's imagine a simple multi-project setup. We'll have a root project, an app subproject, and a lib subproject.
Your settings.gradle would look like this:
// settings.gradle
rootProject.name = 'my-multi-project'
include 'app', 'lib'This tells Gradle about our two subprojects, app and lib.
`implementation` vs. `api`
When declaring inter-project dependencies, you'll typically use configurations like implementation or api.
implementation: The most common choice. The dependency is used internally by the subproject and is not exposed to consumers of that subproject.api: Exposes the dependency to consumers. Ifappdepends onlibviaapi, andotherAppdepends onapp, thenotherAppwill also seelib's API.
For internal use between subprojects, implementation is generally preferred for better encapsulation and faster builds.
The Library Subproject (`lib`)
First, let's create a simple class in our lib subproject that the app subproject will use. This class will provide a basic utility.
Inside lib/src/main/groovy/com/coddykit/LibUtils.groovy:
package com.coddykit
class LibUtils {
static String getGreeting() {
return "Hello from LibUtils!"
}
}App Subproject Using `lib`'s Code
Now, let's make our app subproject use the LibUtils class from our lib subproject. Remember, we declared implementation project(':lib') in app/build.gradle.
Try running this example:
package com.coddykit
import com.coddykit.LibUtils
class AppMain {
static void main(String[] args) {
String message = LibUtils.getGreeting()
System.out.println(message)
}
}Automatic Build Order
One of the biggest advantages of declaring inter-project dependencies is that Gradle automatically figures out the correct build order.
- If
appdepends onlib, Gradle ensures thatlibis compiled and its artifacts are available beforeappstarts its compilation. - This saves you from manually managing build sequences, especially in complex multi-project setups.
When you run gradle build from the root, Gradle will build lib first, then app.
Understanding Transitive Effects
What if your lib subproject itself depends on another subproject, say common?
// lib/build.gradle
dependencies {
implementation project(':common')
}
// app/build.gradle
dependencies {
implementation project(':lib')
}If app depends on lib, and lib depends on common, Gradle will ensure that common is also built and its artifacts are available transitively to app's classpath for compilation, but not necessarily for its API if implementation is used for lib.
Maintain Clean Dependencies
To keep your multi-project builds manageable and efficient, follow these best practices:
- Minimal Dependencies: Only declare dependencies on subprojects you truly need.
- Use
implementation: Preferimplementationoverapifor internal subproject dependencies to improve encapsulation and reduce rebuilds. - Clear Boundaries: Design your subprojects with clear responsibilities to avoid circular dependencies.
- Avoid Deep Paths: Keep subproject paths concise (e.g.,
:module:submoduleis fine, but avoid excessively long paths).
Dependency Declaration Check
You have a multi-project build with a web subproject and a core subproject. The web subproject needs to use classes from the core subproject for its internal logic, but not expose core's API to any further consumers of web.
Inter-Project Dependencies Recap
Great job! In this lesson, you learned how to manage dependencies between subprojects in a Gradle multi-project build.
- We covered how to declare dependencies using
project(':subproject'). - We discussed the importance of
implementationfor internal use. - You saw how Gradle automatically handles build order.
- We explored best practices for clean dependency management.
Mastering inter-project dependencies is key to building large, modular applications efficiently with Gradle!
Häufig gestellte Fragen
Ist die Lektion „Abhängigkeiten zwischen Projekten“ kostenlos?
Ja — der vollständige Text von „Abhängigkeiten zwischen Projekten“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Groovy & Gradle: JVM Automation and Build Engineering-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Groovy & Gradle: JVM Automation and Build Engineering-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Abhängigkeiten zwischen Projekten“?
Verwalten Sie Abhängigkeiten zwischen Teilprojekten und stellen Sie die korrekte Build-Reihenfolge sowie die Artefaktauflösung sicher. Du übst Groovy & Gradle: JVM Automation and Build Engineering mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Groovy & Gradle: JVM Automation and Build Engineering zu starten?
Keine Vorkenntnisse erforderlich. Groovy & Gradle: JVM Automation and Build Engineering auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 3 von 4.
Wie lange dauert die Lektion „Abhängigkeiten zwischen Projekten“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Groovy & Gradle: JVM Automation and Build Engineering-Lektion Code schreiben und ausführen?
Ja. Jede Groovy & Gradle: JVM Automation and Build Engineering-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Monorepo-Projektstruktur
- Teilprojekte und Konfigurationen
- Abhängigkeiten zwischen Projekten
- Composite Builds und Build-Komposition