Groovy & Gradle: JVM Automation and Build Engineering · レッスン

カスタムリポジトリとBOM

カスタムMavenまたはIvyリポジトリを設定し、依存関係のバージョンを統一するためにBill of Materials（BOM）を使用します。

「カスタムリポジトリとBOM」はCoddyKit上の無料Groovy & Gradle: JVM Automation and Build Engineeringレッスンです。これはレッスン3/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはGroovy & Gradle: JVM Automation and Build Engineering学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Groovy & Gradle: JVM Automation and Build Engineeringコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Beyond Maven Central

By default, Gradle looks for dependencies in Maven Central. But what if your dependencies aren't there?

Custom repositories allow you to fetch libraries from other locations, like:

Your company's private artifact server.
Specific public repositories (e.g., Google's Maven repo for Android).
Local file system directories.

Adding a Maven Repository

To add a custom Maven repository, you declare it in the repositories block of your build.gradle file.

Gradle will check repositories in the order they are declared, stopping at the first match.

repositories {
    mavenCentral()
    maven {
        url 'https://repo.spring.io/milestone'
    }
}

Example: Google Maven Repo

Many Android libraries are hosted on Google's Maven repository. You'd add it like this:

This is crucial for projects using Google-specific libraries.

repositories {
    google() // Shortcut for Google's Maven repo
    mavenCentral()
}

Understanding Ivy Repositories

While Maven is very common, Gradle also supports Ivy repositories. Ivy has a more flexible layout for artifacts.

You might encounter Ivy repositories in older projects or specific corporate environments.

repositories {
    ivy {
        url "http://repo.mycompany.com/ivy"
        layout "pattern", {
            artifact "[organization]/[module]/[revision]/[artifact](-[classifier])-[revision].[ext]"
        }
    }
}

Local Directory as Repo

For testing or internal use, you can even use a local directory as a repository. This is handy for sharing artifacts within a team without a dedicated server.

Just specify the path to your local folder.

repositories {
    flatDir {
        dirs 'libs' // Looks for JARs directly in the 'libs' folder
    }
    // Or a more structured Maven-like local repo
    maven {
        url uri('../my-local-maven-repo')
    }
}

Bill of Materials (BOMs)

A Bill of Materials (BOM) is a special Maven POM file that defines a curated list of dependency versions.

It helps manage transitive dependencies and ensures consistent versions across a multi-module project or when using a suite of related libraries.

Consistency with BOMs

BOMs solve a common problem: dependency version conflicts. If multiple libraries depend on different versions of the same transitive dependency, you can end up with unpredictable behavior.

With a BOM, you declare a single "source of truth" for versions, making your build more reliable.

Importing a BOM

To use a BOM in Gradle, you declare it as a dependency using the platform() or enforcedPlatform() function. This tells Gradle to use the versions specified in the BOM.

Notice how we don't specify versions for spring-core or spring-web; the BOM handles it!

dependencies {
    implementation platform('org.springframework.boot:spring-boot-dependencies:2.7.5')

    // These versions are now managed by the BOM
    implementation 'org.springframework:spring-core'
    implementation 'org.springframework:spring-web'
}

Platform vs. EnforcedPlatform

There are two ways to import a BOM:

platform(): Suggests versions. Other modules can override these versions if explicitly declared.
enforcedPlatform(): Strictly enforces versions. Any explicitly declared versions for dependencies in the BOM will be overridden by the BOM's version.

Use enforcedPlatform() for strong version consistency.

Check Your Knowledge

Let's test your understanding of custom repositories and BOMs!

Custom Repos & BOMs Recap

Great job! You've learned how to:

Configure custom Maven and Ivy repositories in Gradle.
Understand the importance of repository order.
Use local directories as repositories.
Leverage Bill of Materials (BOMs) for consistent dependency version management.
Differentiate between platform() and enforcedPlatform().

These techniques are vital for managing complex dependency landscapes in real-world projects!

よくある質問

「カスタムリポジトリとBOM」レッスンは無料ですか？

はい。「カスタムリポジトリとBOM」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Groovy & Gradle: JVM Automation and Build Engineeringコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Groovy & Gradle: JVM Automation and Build Engineeringコースには全4レッスンが含まれています。

「カスタムリポジトリとBOM」で何を学びますか？

カスタムMavenまたはIvyリポジトリを設定し、依存関係のバージョンを統一するためにBill of Materials（BOM）を使用します。ブラウザで直接実行するハンズオンコードでGroovy & Gradle: JVM Automation and Build Engineeringを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Groovy & Gradle: JVM Automation and Build Engineeringを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのGroovy & Gradle: JVM Automation and Build Engineeringは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン3/4です。

「カスタムリポジトリとBOM」レッスンにはどのくらい時間がかかりますか？

ほとんどの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に戻る