component-and-release-boundarieslisted

Deciding what becomes an independently releasable component — a Maven module, a JPMS module, a published library — and what that costs: the tension between reusing code and being able to release it, why a shared jar couples every service depending on it, breaking cycles between components, and judging whether a component is stable enough to depend on. Use when a `common` or `shared` module is proposed or has grown, when extracting code into a library so two services can reuse it, when a dependency cycle appears between Maven modules, when upgrading one library forces a coordinated release of several services, or when services are independently deployable in theory but always ship together. Does not cover cohesion and coupling at class and package level (java-cohesion-coupling), whether a component should become a separate process (distribution-boundaries), the API compatibility of a published type (java-api-design), or wire contract versioning (rpc-and-api-contracts).
robsonkades/agent-skills · ★ 2 · Web & Frontend · score 75

Install: claude install-skill robsonkades/agent-skills

# Component and Release Boundaries ## Purpose This skill uses **release component** for a unit published or deployed on its own schedule and consumed through a versioned contract. Internal Maven or JPMS modules can still be meaningful encapsulation/build components; they simply do not acquire the same external compatibility and release obligations. State which meaning applies before using component metrics. Prevent shared-library changes from unnecessarily forcing fleet-wide upgrades, and avoid publication boundaries whose compatibility and release costs exceed their value. A shared jar or shared version number alone does not establish either failure. Inspect the project's JDK/compiler release, Maven/Gradle configuration, resolved dependency graph, module path versus classpath, publication policy and deployed consumer versions. This skill does not mandate a Java baseline: JPMS requires Java 9+, records Java 16+ and sealed types Java 17+ without preview. Examples are partial illustrations; do not upgrade the project or add modules/dependencies just to reproduce their syntax. ## Workflow 1. **Ask what is released, not what is grouped.** If two candidate components have never been released on different schedules, investigate why. A release train or shared parent version can coordinate independently buildable components without requiring that coordination. Preserve justified encapsulation/build boundaries even when publication stays combined. 2. **Name the consumer