Production Capstone: Build, Test, Secure, Publish, and Optimize a Multi-Module JVM Platform: Requirements, Constraints, and Target Architecture

1. Production brief: Orbit JVM Platform

Orbit is a fictional internal JVM platform with a shared text-normalization library and a small command-line application. Two product teams change application behavior independently, while a platform team owns dependency/version policy and build controls. Releases must run on Java 17, build on controlled JDK 21 agents, and be consumable by one legacy Maven service.

The business requirement is not “use Gradle.” It is: produce a tested, traceable, reproducible artifact that can be promoted without rebuilding, while keeping dependency and credential trust boundaries explicit. Gradle is chosen as the primary implementation because the course has already established its multi-project, platform, test-suite, verification, cache, and publishing models. Maven remains a consumer/interoperability contract—not a second source build.

2. Translate the brief into explicit build requirements

3. Name the state stores before changing any of them

Orbit has several independent state stores. Treating them as “the build cache” would hide important failure modes:

4. Architecture + dependency + build graph

flowchart TD
  W[Verified Gradle Wrapper 9.7.1] -->|launches pinned build tool| G[Gradle runtime on JDK 21]
  G -->|configures settings/build model| R[Root build]
  R -->|project :platform provides constraints| P[:platform java-platform]
  R -->|project :core uses platform + source| C[:core java-library]
  R -->|project :app uses core + platform| A[:app application]
  P -->|version policy edge| C
  P -->|version policy edge| A
  C -->|project dependency/API edge| A
  C -->|unit verification| CT[core:test]
  A -->|unit verification| AT[app:test]
  A -->|integration verification| IT[app:integrationTest]
  CT -->|required by check| Q[check gate]
  AT -->|required by check| Q
  IT -->|explicitly attached| Q
  Q -->|accepted component| PUB[staging publication]

The wrapper-to-Gradle arrow transfers executable tool identity. Gradle-to-root transfers the configured model. Platform-to-core/app arrows transfer version constraints, not JAR code. Core-to-app transfers compiled API/runtime classes. Test arrows transfer pass/fail evidence into the check gate. Only an accepted gate may feed the staging publication.

5. Trust boundary + artifact + evidence flow

flowchart TD
  SRC[Reviewed source + governance] -->|hash source manifest| BUILD[Ephemeral build workspace]
  UP[(Maven Central)] -->|verified dependency bytes| BUILD
  BUILD -->|test XML/HTML + tool identity| EVID[Evidence bundle]
  BUILD -->|core-1.0.0.jar + POM + module metadata| STAGE[(Disposable staging repo)]
  STAGE -->|SHA-256 verified, copy exact bytes| REL[(Disposable release repo)]
  REL -->|Maven repository contract| MC[Maven 3.9.16 clean consumer]
  EVID -->|binds source + tests + checksums| APPROVE[Promotion decision]
  APPROVE -->|authorizes copy, never rebuild| REL
  CACHE[(Dependency/build caches)] -->|read only if trust policy allows| BUILD
  BUILD -->|write only from approved lane| CACHE

The upstream repository is outside the project trust boundary, so its artifacts require repository policy and verification metadata. The build workspace is disposable. Staging is not release authority. The promotion decision consumes evidence, and the release repository receives bytes copied from staging. The Maven consumer proves an external metadata contract. Cache arrows are conditional: a cache hit is accepted only when the cache writer/read policy matches the build’s trust level.

6. Write invariants before implementation

7. Pin the current baseline explicitly

8. Read-only preflight before creating the capstone

Start from identity and filesystem evidence. Do not generate wrappers or mutate caches yet:

java -version
javac -version

test -f gradlew && ./gradlew -version || true
test -f gradle/wrapper/gradle-wrapper.properties && cat gradle/wrapper/gradle-wrapper.properties || true

git status --short 2>/dev/null || true
pwd
python --version

If the project Wrapper is not present, bootstrap it only from a trusted Gradle 9.7.1 installation or from a previously reviewed course skeleton. A wrapper script downloaded ad hoc from an arbitrary source defeats invariant I-01 before the build begins.

9. Mandatory local/free path and optional enterprise boundaries

The mandatory capstone requires only a JDK, the checked-in wrapper, Git/Python/shell utilities, Maven Central for initial external dependencies, and project-local directories. Staging and release repositories are ordinary directories using Maven repository layout. The Maven consumer uses an isolated local repository.

Hosted CI, Nexus/Artifactory, Develocity, remote HTTP build caches, HSM-backed signing, and cloud secret managers are valid production integrations but are not required here. Their role is represented as an interface contract: trusted inputs, writers/readers, authentication, retention, immutable promotion, and evidence export.

10. Why Gradle primary + Maven boundary is the chosen architecture

11. Implementation order is itself a control

Lesson 2 follows this dependency order: wrapper/toolchain → settings/repositories → module graph → version policy → tests → lock/verification metadata → packaging → staging publication → clean Maven consumption → evidence bundle → immutable promotion → performance baseline. Later steps depend on evidence produced by earlier steps. Do not start by copying a giant final build script: incremental construction makes causal failures visible.

Knowledge check

Official references and version notes

• Gradle 9.7.1 release notes — pinned Gradle baseline for the capstone.
• Gradle Wrapper and release checksums — wrapper/distribution identity and integrity.
• Gradle JVM toolchains — build JVM versus compiler/test launchers.
• Dependency verification — checksum/signature verification metadata and review workflow.
• Repository declarations and content filtering — dependency origin controls.
• Java testing and JVM Test Suite — unit/integration verification model.
• Maven Publish — Gradle publication to Maven repository layout and clean Maven consumption.
• Build Cache and Configuration Cache — bounded build-state reuse.
• Gradle performance guidance — measurement-first optimization and profiling.
• Apache Maven release history — Maven 3.9.16 GA consumer baseline; Maven 4.0.0-rc-6 remains pre-GA.
• Apache Maven Wrapper 3.3.4 — stable Maven Wrapper baseline.
• Maven Compiler Plugin 3.15.0 — clean Maven consumer compilation baseline.
• JUnit 6.1.3 — Java 17+ test runtime baseline.
• Apache Commons Lang release notes — Commons Lang 3.20.0 dependency baseline.

Version-sensitive statements were rechecked against primary documentation on 2026-08-24. Mandatory work remains local/free. Hosted CI, commercial build analytics, production repository managers, remote caches, and real signing/credential systems are optional integration boundaries only.