Groovy & Gradle: JVM Automation and Build Engineering · 课时

项目间依赖

管理子项目之间的依赖，确保正确的构建顺序和构件解析。

项目间依赖 是 CoddyKit 上的免费 Groovy & Gradle: JVM Automation and Build Engineering 课时。这是第 3 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 Groovy & Gradle: JVM Automation and Build Engineering 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Groovy & Gradle: JVM Automation and Build Engineering 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

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. If app depends on lib via api, and otherApp depends on app, then otherApp will also see lib'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 app depends on lib, Gradle ensures that lib is compiled and its artifacts are available before app starts 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: Prefer implementation over api for 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:submodule is 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 implementation for 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!

常见问题解答

「项目间依赖」课时是免费的吗？

是的 — 「项目间依赖」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Groovy & Gradle: JVM Automation and Build Engineering 课程的其余内容，请升级到 CoddyKit PRO。 Groovy & Gradle: JVM Automation and Build Engineering 课程共包含 4 节课。

「项目间依赖」这节课中我会学到什么？

管理子项目之间的依赖，确保正确的构建顺序和构件解析。你通过在浏览器中直接运行的动手代码来练习 Groovy & Gradle: JVM Automation and Build Engineering，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Groovy & Gradle: JVM Automation and Build Engineering 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Groovy & Gradle: JVM Automation and Build Engineering 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 3 节课，共 4 节。

「项目间依赖」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Groovy & Gradle: JVM Automation and Build Engineering 课中编写并运行代码吗？

能。每节 Groovy & Gradle: JVM Automation and Build Engineering 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Groovy & Gradle: JVM Automation and Build Engineering