搜索

PythonReactSEOPDF
GitHub Skill

gradle-standards

Gradle build configuration standards for Java projects. Covers version catalogs, dependency bundles, multi-module setup, BOM management, and common troubleshooting. Use when configuring Gradle builds or reviewing dependency management.

bitsoex☆ 35 仓库 Stars30 仓库 Forks

安装与使用

请根据来源仓库和你的 AI 工具说明安装此技能。先阅读技能文件和依赖要求,再添加到工作流。

查看来源 ↗使用指南

技能说明

Gradle Standards

Standards for Gradle configuration in Java projects, including version catalogs, dependency bundles, and multi-module setup.

When to use this skill

  • Setting up a new Gradle project
  • Adding or updating dependencies
  • Configuring multi-module builds
  • Troubleshooting dependency conflicts
  • Migrating to version catalogs
  • Cleaning up unused dependencies
  • Optimizing build performance

Skill Contents

Sections
Available Resources

📚 references/ - Detailed documentation


Quick Start

1. Version Centralization (Required)

All versions MUST be centralized in gradle/libs.versions.toml:

[versions]
spring-boot = "3.5.9"
grpc = "1.78.0"

[libraries]
spring-boot-starter-web = { module = "org.springframework.boot:spring-boot-starter-web", version.ref = "spring-boot" }
spring-boot-starter-actuator = { module = "org.springframework.boot:spring-boot-starter-actuator", version.ref = "spring-boot" }
2. Use in build.gradle
dependencies {
    // ✅ CORRECT: Use version catalog with explicit dependencies
    implementation libs.spring.boot.starter.web
    implementation libs.spring.boot.starter.actuator

    // ❌ NEVER: Hardcode versions
    // implementation "org.springframework.boot:spring-boot-starter-web:3.5.9"
}

Key Principles

Principle Description
Centralize Versions All versions in libs.versions.toml, never inline
Explicit Dependencies Declare each dependency explicitly for clarity
Use Align Rules Nebula align rules ensure version consistency across module groups
Never Downgrade Don't replace existing versions with older ones
Trust BOMs Spring Boot BOM manages transitive dependencies
Platform Over Enforce Use platform(), never enforcedPlatform()
Use Nebula for Resolution Use resolution rules + lock files, not force/constraints
Lock Dependencies Generate gradle.lockfile for ALL submodules (use build --write-locks)

Version Alignment

Use Nebula align rules to ensure all modules in a library group use the same version. This is preferred over bundles because:

  • Subprojects can declare exactly what they need
  • Dependencies are explicit and visible in build files
  • Version consistency is enforced at resolution time
// gradle/resolution-rules.json
{
  "align": [
    {
      "name": "jackson-alignment",
      "group": "com\\.fasterxml\\.jackson\\.core",
      "reason": "Jackson modules must use same version"
    },
    {
      "name": "grpc-alignment",
      "group": "io\\.grpc",
      "reason": "gRPC modules must align for binary compatibility"
    }
  ]
}

See Nebula resolution rules documentation for complete align rule reference.

References

Reference Description
references/version-catalogs.md Complete version catalog guide
references/multi-module.md Multi-module project setup
references/native-dependency-locking.md Gradle native locking (Gradle 9+ recommended)
references/cleanup-workflow.md Dependency cleanup process
references/unused-detection.md Finding unused dependencies
references/optimization.md Build optimization techniques
references/troubleshooting.md Common issues and solutions

Related Rules

  • .cursor/rules/java-gradle-best-practices.mdc - Full Gradle configuration reference
  • .cursor/rules/java-versions-and-dependencies.mdc - Version management policies

Dependency Resolution Stack

┌─────────────────────────────────────────────────────────────────────┐
│  1. VERSION CATALOG (libs.versions.toml)                            │
│     Single source of truth for declared versions                    │
├─────────────────────────────────────────────────────────────────────┤
│  2. RESOLUTION RULES (optional: resolution-rules.json)              │
│     Policies: substitute, align, deny, exclude                      │
│     Use substitute for security fixes, align for module groups      │
├─────────────────────────────────────────────────────────────────────┤
│  3. LOCK FILE (captures EXACT resolved versions)                    │
│     Option A: gradle.lockfile (native - Gradle 9+ recommended)      │
│     Option B: dependencies.lock (Nebula plugin)                     │
│                                                                     │
│  ⚠️  CRITICAL: Multi-module projects need lockfiles for ALL modules │
│     Use: ./gradlew build --write-locks -x test                      │
│     NOT: ./gradlew dependencies --write-locks (root only!)          │
└─────────────────────────────────────────────────────────────────────┘

Lock File Options:

Multi-Module Lockfile Generation:

# ✅ CORRECT: Generates lockfiles for ALL submodules
./gradlew build --write-locks -x test

# ❌ WRONG: Only generates for ROOT project
./gradlew dependencies --write-locks

# Verify coverage (lockfiles should ≈ build.gradle files)
find . -name "gradle.lockfile" | wc -l
find . -name "build.gradle" | wc -l

Related Skills

Skill Purpose
dependency-management Version catalogs and BOMs
dependabot-security Security vulnerability fixes
java-coverage JaCoCo configuration in Gradle
java-testing Test configuration with Spock

使用示例

查看来源仓库中的使用示例与配置说明。

查看来源 ↗

来源历史

收录时间
2026-01-20
索引更新时间
2026-01-28
Branch
main

收录与同步日期属于本站记录。源码修改历史请查看来源仓库。

GitHub ↗

chat Comments (0)

chat_bubble_outline

No comments yet. Be the first to share your thoughts!