Groovy & Gradle: JVM Automation and Build Engineering · 강의

규칙 플러그인과 빌드 로직

조직 전체에서 일관된 빌드 구성과 표준을 적용하도록 규칙 플러그인을 개발하고 적용합니다.

규칙 플러그인과 빌드 로직은(는) CoddyKit의 무료 Groovy & Gradle: JVM Automation and Build Engineering 강의입니다. 이것은 4개 중 3번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Groovy & Gradle: JVM Automation and Build Engineering 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Groovy & Gradle: JVM Automation and Build Engineering 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

What are Convention Plugins?

In large Gradle multi-project builds, maintaining consistent configurations across many subprojects can become a challenge. This is where Convention Plugins come in handy.

A convention plugin is essentially a way to package and reuse common build logic and configurations specific to your organization or project. They help enforce standards and reduce boilerplate.

The Problem: Inconsistent Build Logic

Imagine you have several Java subprojects. Each needs to apply the java-library plugin, set a specific Java toolchain, and configure common repositories. Without convention plugins, you might end up with repetitive and slightly different configurations in each build.gradle file.

/* project-a/build.gradle */
plugins {
    id 'java-library'
}
java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}
repositories {
    mavenCentral()
}

/* project-b/build.gradle */
plugins {
    id 'java-library'
}
java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}
repositories {
    mavenCentral()
}

Centralizing Build Logic with `buildSrc`

To solve the problem of repetition, Gradle offers a special directory: buildSrc. When present in your project root, Gradle automatically compiles any code (Groovy, Kotlin, Java) found within buildSrc and adds it to the classpath of your build scripts.

This makes buildSrc the perfect place to define internal build logic, custom tasks, and especially, convention plugins.

Crafting Your First Convention Plugin

Let's create a simple convention plugin to standardize our Java library setup. We'll define it in buildSrc/src/main/groovy/my.java-conventions.groovy. This plugin will apply the java-library plugin, set Java 17 as the toolchain, and add mavenCentral().

// buildSrc/src/main/groovy/my.java-conventions.groovy
plugins {
    id 'java-library'
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

repositories {
    mavenCentral()
}

Applying Your Convention Plugin

Once you've defined your convention plugin in buildSrc, you can apply it to any subproject's build.gradle file using its ID. Notice how much cleaner and more concise the subproject's build file becomes!

// subproject-a/build.gradle
plugins {
    id 'my.java-conventions'
}

// All Java library, Java 17, and Maven Central settings
// are now applied automatically by the convention plugin!

Expanding Conventions: Dependencies & Tests

Convention plugins can do much more than just basic settings. You can enforce common dependencies, configure testing frameworks, or standardize other build aspects. Here, we add JUnit Jupiter dependencies and a common test logging configuration.

// buildSrc/src/main/groovy/my.java-conventions.groovy (updated)
plugins {
    id 'java-library'
}
// ... (previous Java toolchain and repositories config)

dependencies {
    testImplementation platform('org.junit:junit-bom:5.10.0')
    testImplementation 'org.junit.jupiter:junit-jupiter'
}

test {
    useJUnitPlatform()
    testLogging {
        events "passed", "skipped", "failed"
    }
}

Convention Plugins with Kotlin DSL

Just like regular build scripts, convention plugins can also be written using the Kotlin DSL (.gradle.kts files). This provides compile-time safety and better IDE support, which can be very valuable for complex build logic.

The structure remains similar, just with Kotlin syntax.

// buildSrc/src/main/kotlin/my.kotlin-conventions.gradle.kts
plugins {
    java
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(21)
    }
}

repositories {
    mavenCentral()
}

Applying to the Root Project

While convention plugins are often used for subprojects, they can also be applied to the root project's build.gradle. This is useful for defining build-wide properties or configurations that should apply to the entire project, like common dependency versions.

// build.gradle (root project)
plugins {
    id 'my.root-conventions'
}

// buildSrc/src/main/groovy/my.root-conventions.groovy
ext {
    // Define properties accessible throughout the build
    springBootVersion = '3.2.0'
    kotlinVersion = '1.9.0'
}

Benefits and Best Practices

Convention plugins are a cornerstone of maintainable, large-scale Gradle builds:

Consistency: Ensures all projects adhere to organizational standards.
Reduced Duplication: Centralizes common build logic, eliminating copy-pasting.
Easier Maintenance: Update standards in one place; all projects instantly benefit.
Improved Readability: Subproject build files become shorter and more focused on project-specific details.

When creating them, keep plugins focused on a single concern, use clear IDs, and leverage Kotlin DSL for type safety.

Convention Checkpoint

Convention plugins are a powerful way to standardize build logic and enforce organizational standards. Let's test your understanding.

Recap: Mastering Convention Plugins

You've now learned about Gradle Convention Plugins! They are an essential tool for managing complex, multi-project builds.

Convention plugins centralize common build logic.
They are typically defined in the buildSrc directory.
They help enforce consistent configurations (Java versions, dependencies, test setups).
They drastically reduce boilerplate and improve maintainability.

By leveraging convention plugins, you can build more robust and scalable Gradle projects.

자주 묻는 질문

“규칙 플러그인과 빌드 로직” 강의는 무료인가요?

네 — “규칙 플러그인과 빌드 로직” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Groovy & Gradle: JVM Automation and Build Engineering 강의 전체를 잠금 해제할 수 있습니다. Groovy & Gradle: JVM Automation and Build Engineering 강의에는 총 4개의 강의가 포함되어 있습니다.

“규칙 플러그인과 빌드 로직”에서 뭘 배우나요?

조직 전체에서 일관된 빌드 구성과 표준을 적용하도록 규칙 플러그인을 개발하고 적용합니다. 브라우저에서 직접 실행하는 실습 코드로 Groovy & Gradle: JVM Automation and Build Engineering을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Groovy & Gradle: JVM Automation and Build Engineering을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Groovy & Gradle: JVM Automation and Build Engineering은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 3번째 강의입니다.

“규칙 플러그인과 빌드 로직” 강의는 얼마나 걸리나요?

대부분의 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(으)로 돌아가기