[EPIC] Java Version Override Support in CI/CD

Epic: Java Version Override Support in CI/CD

Goal

Enable building, testing, and releasing dotCMS with any Java version (e.g. 21, 25, 26+) without changing .sdkmanrc, while ensuring artifacts from different Java versions never collide.

This capability is required to safely validate newer Java versions in parallel with the current default and to support staged rollout into production workflows.

---

Outcome / Success Criteria

• A workflow can be triggered with an optional Java version override.
• When an override is provided:
  • The correct JDK is used for build and runtime.
  • Maven bytecode targets the overridden major version.
  • All generated artifacts (Docker images, caches, GitHub artifacts) are isolated by Java version.
• When no override is provided:
  • Existing workflows behave exactly as they do today (no breaking changes).
• The solution is version-agnostic (not hardcoded to Java 25).

---

Assumptions and decisions

• Single Java version per workflow run (multi-version builds may be added later if needed).
• Java version identification will initially be based on major version only (e.g. java21, java25).
• Artifact and image names must be namespaced only when an override is used.
• Release workflow changes will be done last, after validation in non-production workflows.

These decisions need to be finalized

---

Scope

In Scope

• Adding optional Java override support to reusable CI/CD actions.
• Propagating the override cleanly through initialize → build → test → deploy phases.
• Preventing artifact, cache, and Docker tag collisions across Java versions.
• Introducing at least one manual workflow for safe validation.

Out of Scope

• Building multiple Java versions in a single workflow run.
• Changing the default Java version in .sdkmanrc.
• Refactoring unrelated CI/CD logic.

---

Key Constraints / Risks

• GitHub Actions security model means PRs cannot test workflow changes until merged to main.
• Partial implementation (some artifacts versioned, others not) will cause collisions.
• Overriding the JDK without also overriding Maven compiler settings is invalid.

These constraints must be respected by all subtasks under this epic.

---

Implementation Notes

This epic intentionally separates what must be achieved from how it is implemented.

Detailed design rationale, trade-offs, rollout sequencing, and file-level guidance are documented here:
👉 Java Version Override – Design & Implementation Notes

Subtasks should reference that document as needed, but should remain focused on execution.

---

Subtasks (to be created)

• Add Java override parameters to core CI/CD actions (backward compatible)
• Introduce manual workflow for testing Java overrides
• Add override support to nightly workflow (optional)
• Add override support to trunk workflow
• Add override support to release workflow (final step)

Start with the linked Java Version Override design notes, then inspect the existing reusable CI/CD actions and workflows and the current .sdkmanrc usage. Trace how Java versions, Maven targets, caches, artifacts, and Docker images move through initialize, build, test, deploy, and release. Done means an optional major-version override works without changing default behavior and prevents cross-version collisions.