Production Capstone: Build, Test, Secure, Publish, and Optimize a Multi-Module JVM Platform: Security, Governance, and Reliability Validation

1. Security controls form a chain, not a checklist

Consider the capstone as six linked control layers. A weakness at one layer can invalidate confidence produced by another:

2. Revalidate executable bootstrap identity

Before trusting any new evidence, recheck the bootstrap:

grep '^distributionUrl=' gradle/wrapper/gradle-wrapper.properties
grep '^distributionSha256Sum=' gradle/wrapper/gradle-wrapper.properties
sha256sum gradle/wrapper/gradle-wrapper.jar
printf 'expected wrapper jar: 7a9ce74cff467ca1bf60a4fcd9f05185acceda4d0f382434d393e17864262c5d
'
./gradlew -version

If a Wrapper file changes, invalidate prior bootstrap evidence even if application source is unchanged. Executable build logic is part of the supply chain.

3. Prove dependency/plugin origin separately from version selection

Version governance answers “which version?” Repository policy answers “from where?” Dependency verification answers “which bytes?” Keep them distinct:

./gradlew :core:dependencyInsight \
  --dependency org.apache.commons:commons-lang3 \
  --configuration runtimeClasspath

sed -n '1,180p' settings.gradle.kts
sed -n '1,260p' gradle/verification-metadata.xml

For this capstone, project repositories are forbidden and Maven Central is the declared external dependency source. Core Gradle plugins ship with the pinned Gradle distribution; no community plugin is required. That reduces—but does not eliminate—the executable supply-chain surface.

4. Prove declared intent and resolved state

Inspect the platform constraints, versionless catalog aliases, lockfiles, and resolved graph together. None is a universal substitute for the others:

sed -n '1,220p' platform/build.gradle.kts
cat gradle/libs.versions.toml
find . -name gradle.lockfile -print -exec sed -n '1,120p' {} \;
./gradlew :core:dependencies --configuration runtimeClasspath

Expected: the catalog expresses coordinates, the platform expresses accepted versions, lock state captures selected versions for locked configurations, and dependency reports show the actual graph.

5. Validate credential containment

The mandatory path has no real credentials. Still, scan source/governance/evidence before handoff:

grep -RInE '(password|passwd|secret|token|private[_-]?key|BEGIN .*PRIVATE KEY)' \
  --exclude-dir=.git --exclude-dir=.gradle --exclude-dir=.lab-gradle \
  --exclude-dir=build --exclude-dir=staging-repo --exclude-dir=release-repo . || true

Review every match; words such as “secret policy” in documentation are not leaks. In production, secrets belong in the CI/credential system and should be supplied via appropriately scoped providers, never committed to build scripts, logs, Build Scans, or command history.

6. Reproducibility requires independent workspaces

Re-run the clean-room test from Lesson 2 and record:

If checksums differ, do not hide the difference. Inspect ZIP entry ordering/timestamps, generated files, manifests, absolute paths, locale/timezone influence, tool/JDK drift, and undeclared environment inputs.

7. Trace promoted bytes back to source and tests

Create a concise evidence chain:

source-files.sha256
  -> wrapper/JDK identity
  -> dependency graph + lock/verification metadata
  -> unit + integration test reports
  -> staged core-1.0.0.jar SHA-256
  -> staging POM/module metadata
  -> promotion checksum equality
  -> release core-1.0.0.jar SHA-256
  -> Maven clean-consumer compile evidence

Traceability fails if any link is replaced with an assertion such as “CI was green” without the actual report/artifact identity.

8. Three claims that must not be collapsed

9. Test the main architecture tradeoffs

10. Optimize only a measured critical path

Compare profile reports under the same source, JDK, test set, cache mode, and worker settings. If configuration dominates, improve configuration behavior; if one test task dominates, investigate that test path; if dependency resolution dominates only on cold agents, cache/network policy may matter. Do not disable tests, verification, or declared inputs to make the profile prettier.

After any optimization, rerun clean check, clean-room reproducibility, staged checksum capture, and the relevant failure drill. Performance changes are build-logic changes and can alter correctness.

11. Evidence matrix: invariant → source → verification → failure → owner

12. Reliability acceptance gate

Before failure injection, freeze a known-good evidence snapshot: source manifest, wrapper/JDK identity, dependency reports, lockfiles, verification metadata, unit/integration report paths, clean-room hashes, staged/release hashes, Maven consumer result, and profile baseline. That snapshot is the reference state for every drill in Lesson 4.

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.