Skip to content
cccskills
FreePublished on GitHub

build-tooling

Maven and Gradle build tool conventions for Java projects: build tool detection, wrapper usage, dependency management, BOMs, plugin configuration, semver, and multi-module layouts. Stack-agnostic — referenced by every Java plugin in the marketplace. Use this skill to: - Detect which build tool is in use and invoke it correctly. - Manage dependencies safely (BOMs, version properties, no wildcard versions). - Configure compiler, test, and code-quality plugins. - Handle multi-module projects. Do NOT use this skill for: - Framework-specific build plugins (Spring Boot Gradle plugin — in spring-boot-plugin:spring-conventions). - CI/CD pipeline config.

The English summary is being prepared. Showing the original description.

Run score Not tested

See how to install

Files included (1)

  • SKILL.md6.3 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Build Tooling (Maven & Gradle, stack-agnostic)

Build tool detection

Determine the build tool at the start of every task:

SignalTool
pom.xml existsMaven
build.gradle existsGradle (Groovy DSL)
build.gradle.kts existsGradle (Kotlin DSL)
Both pom.xml and build.gradle*Unusual — flag and ask; never assume

Always use the wrapper

Never invoke mvn or gradle directly — use the wrapper so the team's pinned version runs.

# Maven
./mvnw <goal>            # Unix
mvnw.cmd <goal>          # Windows (if needed)

# Gradle
./gradlew <task>

If the wrapper is absent, flag it in DECISIONS and fall back to the system binary, but note that pinning is missing.

Maven — key conventions

Dependency management

<!-- Declare versions in <properties> — never inline literals -->
<properties>
    <java.version>21</java.version>
    <mapstruct.version>1.6.3</mapstruct.version>
</properties>

<!-- Import a BOM in dependencyManagement to align a family of deps -->
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>${spring-boot.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<!-- Declare individual deps without <version> when BOM covers them -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Never use LATEST or RELEASE as versions — they are non-reproducible. Pin explicitly or let a BOM manage.

Useful goals

./mvnw compile                          # compile only
./mvnw test                             # compile + test
./mvnw package -DskipTests              # build JAR/WAR, skip tests
./mvnw verify                           # full build incl. integration tests
./mvnw dependency:tree                  # show resolved dependency tree
./mvnw versions:display-dependency-updates   # check for outdated deps

Multi-module Maven

Root pom.xml declares <packaging>pom</packaging> and <modules> list. Child modules inherit groupId and version from parent. Use <dependencyManagement> in root to align versions across modules — child modules do not repeat versions.

Gradle — key conventions

Kotlin DSL (build.gradle.kts) — preferred in new projects

plugins {
    java
    application
}

group = "com.example"
version = "1.0.0"

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

repositories {
    mavenCentral()
}

dependencies {
    // Import a BOM (platform)
    implementation(platform("io.quarkus:quarkus-bom:3.18.0"))
    implementation("io.quarkus:quarkus-resteasy-reactive")

    testImplementation("org.junit.jupiter:junit-jupiter")
    testRuntimeOnly("org.junit.platform:junit-platform-launcher")
}

tasks.test {
    useJUnitPlatform()
}

Groovy DSL (build.gradle) — legacy projects

plugins {
    id 'java'
}

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

dependencies {
    implementation platform('io.quarkus:quarkus-bom:3.18.0')
    implementation 'io.quarkus:quarkus-resteasy-reactive'

    testImplementation 'org.junit.jupiter:junit-jupiter'
}

test {
    useJUnitPlatform()
}

Useful tasks

./gradlew build            # compile + test + assemble
./gradlew test             # test only
./gradlew assemble         # build without tests
./gradlew dependencies     # dependency tree
./gradlew dependencyUpdates  # with ben-manes/versions plugin

Java toolchain (Gradle 7.6+)

Prefer java { toolchain { ... } } over sourceCompatibility / targetCompatibility. The toolchain block pins the JDK version independently of the JDK running Gradle itself, ensuring reproducibility across machines.

Dependency version discipline

  • Use a BOM for any framework with a family of aligned artifacts (Spring Boot, Quarkus, Micronaut).
  • Declare versions in one place — Maven <properties>, Gradle libs.versions.toml (version catalog), or the BOM.
  • No wildcard or range versions ([1.0,), LATEST, RELEASE, +).
  • Test-scope only for test frameworks (JUnit, Mockito, AssertJ, Testcontainers).
  • Provided/compileOnly for things the container supplies at runtime (Jakarta EE APIs, lombok annotations if used).

Adding a new dependency — checklist

  1. Check if the BOM already manages the version — if so, omit the version.
  2. Add to the correct scope (implementation / testImplementation / compileOnly).
  3. Verify no transitive conflict: run ./mvnw dependency:tree or ./gradlew dependencies.
  4. Record in DECISIONS if adding a new non-trivial dependency.

Common Maven plugins (when not already configured)

<!-- Enforce minimum Maven version and dependency convergence -->
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-enforcer-plugin</artifactId>
    <executions>
        <execution>
            <id>enforce</id>
            <goals><goal>enforce</goal></goals>
            <configuration>
                <rules>
                    <requireMavenVersion><version>3.8</version></requireMavenVersion>
                    <dependencyConvergence/>
                </rules>
            </configuration>
        </execution>
    </executions>
</plugin>

Do not add plugins that aren't already present unless the BA spec calls for it — document in DECISIONS.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Angular 18-21 project structure, standalone components vs NgModule, control flow (@if/@for/@switch + *ngIf/*ngFor legacy), decorators, dependency injection (inject() function), lifecycle hooks, pipes, Angular Universal SSR pointer. Use this skill to: - Detect project style (standalone vs NgModule) and apply matching patterns. - Pick correct decorators and DI approach. - Use modern control flow (@if/@for/@switch) in Angular 17+ projects. - Apply `inject()` function over constructor injection where appropriate. - Wire bootstrap correctly (bootstrapApplication for standalone, AppModule for legacy). Do NOT use this skill for: - State management (see angular-state-and-rx). - Routing (see angular-routing). - Forms (see angular-forms). - Testing (see angular-testing).

The English summary is being prepared. Showing the original description.

AratKruglik/claude-sdlc48Updated Oct 17, 2026

Angular forms: Reactive Forms (preferred — typed FormGroup/FormControl since Angular 14, FormBuilder, custom + async validators, FormArray, multi-step) and Template-driven (`[(ngModel)]` + FormsModule). Validation strategies, server error mapping, accessibility. Use this skill to: - Build Reactive Forms with typed FormGroup/FormControl. - Use FormBuilder для concise syntax. - Implement custom synchronous and async validators. - Wire FormArray for dynamic field lists. - Map server errors back to form fields. - Pick Reactive vs Template-driven (prefer Reactive). Do NOT use this skill for: - General conventions (see angular-conventions). - State management beyond forms (see angular-state-and-rx). - Routing (see angular-routing). - Testing forms (see angular-testing).

The English summary is being prepared. Showing the original description.

AratKruglik/claude-sdlc48Updated Oct 17, 2026

Angular Router (built-in `@angular/router`) — route configuration for standalone and NgModule projects, functional guards (Angular 14.1+), lazy loading, route resolvers, typed params via signals/observables, programmatic navigation, route data and meta. Use this skill to: - Configure routes (standalone-style or NgModule-style). - Use functional guards (canActivate as function, preferred over class-based in 17+). - Lazy-load components or feature modules. - Implement auth guards via route meta + functional guards. - Read params/queries via `inject(ActivatedRoute)` + signals or RxJS. Do NOT use this skill for: - General conventions (see angular-conventions). - State management (see angular-state-and-rx). - Forms (see angular-forms). - Testing routes (see angular-testing).

The English summary is being prepared. Showing the original description.

AratKruglik/claude-sdlc48Updated Oct 17, 2026

State management for Angular 18-21: signals (signal/computed/effect), services-as-state, NgRx Store + Effects + Selectors, NgRx Component Store, NgRx Signals (newer signal-based store). RxJS essentials — operators, async pipe, takeUntilDestroyed, signal/observable interop. Use this skill to: - Pick the right state tool (signals / services / NgRx variant / vue-query equivalent). - Use signals correctly (signal/computed/effect — when each). - Build a Pinia-style service-as-state singleton. - Set up NgRx Store + Effects + Selectors. - Use RxJS without leaking subscriptions (async pipe, takeUntilDestroyed, Subject patterns). - Bridge signals ↔ observables via toSignal / toObservable. Do NOT use this skill for: - General Angular conventions (see angular-conventions). - Routing state (see angular-routing). - Form state (see angular-forms). - Testing state (see angular-testing).

The English summary is being prepared. Showing the original description.

AratKruglik/claude-sdlc48Updated Oct 17, 2026

Testing Angular 18-21: TestBed, component harnesses (@angular/cdk/testing), Karma+Jasmine (default historical) vs Jest (jest-preset-angular, modern), Angular Testing Library (RTL-style). HttpClient mocking via HttpTestingController. NgRx Effects testing. Cypress / Playwright e2e. Use this skill to: - Detect runner (Karma+Jasmine vs Jest) and configure correctly. - Write component tests with TestBed. - Use component harnesses for Material / custom UI components. - Mock HttpClient via provideHttpClientTesting + HttpTestingController. - Test signal-based inputs with componentRef.setInput(). - Test NgRx Effects with provideMockActions. Do NOT use this skill for: - General Angular conventions (see angular-conventions). - Routing patterns broadly (see angular-routing — covers testing routes briefly). - Form patterns broadly (see angular-forms).

The English summary is being prepared. Showing the original description.

AratKruglik/claude-sdlc48Updated Oct 17, 2026

Shared conventions for every SDLC development-phase architect agent: hard rules, code quality bar, workflow steps (superpowers invocation, spec reading, codebase exploration, verification), and the report/compact-summary contract. Architects load this skill first, then apply their stack-specific instructions on top.

The English summary is being prepared. Showing the original description.

AratKruglik/claude-sdlc48Updated Oct 17, 2026

See all skills by AratKruglik

Report a problem with this skill