[wezell]

Requested outcome

Build SAML from source with every core release, publish its matching JAR and POM, and automatically reference and package that exact artifact, as Tika already does. This is the ongoing integration the developer selected, not a one-off standalone release.

Scope

This PR contains spec.md only. It requires version alignment (including supported Java variants), existing artifact coordinates and OSGi identity, retained SAML regression/security coverage, clean build ordering, matching published/packaged checksums, and fail-closed artifact checks.

No code, build, dependency pin, existing release artifact, or historical tag was changed. Unrelated dependency upgrades and the plugin-examples dispatch failure are out of scope.

Source and related work

The proposed source baseline is the reviewed upstream main commit 2006c0fa021f21dd78db9c9d467bac6cb43e7aff, including response validation from dotCMS/com.dotcms.dotsaml#25. The standalone SAML 26.10.17 release is now merged (dotCMS/com.dotcms.dotsaml#26, October 20); the separate core version-pin PR remains open (#38083). They are related work, not prerequisites for the automatic integration specified here. The spec records their status at creation on October 19.

Review gate

Please approve the scope and acceptance criteria before implementation planning begins. After approval, implementation proceeds on a branch from this spec with ADR consultation, developer-approved failing tests, and the required convergence check before PR 2.

Spec completeness and whitespace checks passed. The unchanged standalone SAML baseline and existing 26.10.17 release candidate each built successfully with JDK 21 and 92 tests passing (zero failed, errored, or skipped). These are baseline results only: the automatic core integration and its release/runtime validation do not exist yet. Erick approved the current spec commit f255de86dc on October 20; no spec text has changed since that approval.

Refs #38104

This PR fixes: #38104

This PR fixes: #38104

[claude]

Claude finished @wezell's task in 1m 0s —— View job

---

Spec review — specs/20261019-221619-saml-release/spec.md

• Read the spec and gather repo context
• Verify factual claims against the codebase
• Post review

This PR adds spec.md only — no code — so this is a review of the specification's accuracy, completeness, and internal consistency against the Spec-Kit flow, not a code review.

Factual claims verified against the repo

• The core premise checks out. osgi-base/system-bundles/pom.xml:37-39 pins SAML at a hardcoded 26.08.21, while Tika at osgi-base/system-bundles/pom.xml:26-27 uses ${project.version}. That is exactly the divergence FR-002/FR-004 target, and the "Tika already follows the lifecycle" claim (line 74, 91) is accurate.
• Coordinates are correct. com.dotcms.samlbundle:com.dotcms.samlbundle (FR-003, line 69) matches the actual groupId/artifactId in the pom.
• Credential names are real. MAVEN_BUNNY_RW_USERNAME / MAVEN_BUNNY_RW_PASSWORD (FR-003) are the credentials used across .github/workflows/cicd_6-release.yml, cicd_comp_release-phase.yml, and deploy-bunny-maven-s3. Reusing them rather than minting new secrets is consistent with the existing release path.

Observations

• 🟡 Minor — spec.md:96: the Assumptions section names "the pending standalone SAML 26.10.17 release," but that version string appears nowhere else in the spec (the Problem section works from 26.08.21 and 26.10.19-01) and the PR body refers to the pending standalone release only by issue number (dotCMS/com.dotcms.dotsaml#26). If 26.10.17 is deliberate, fine; if it's a stale number, drop it and keep the issue reference so the spec doesn't anchor to a version that may change.

• 🟡 Worth making explicit — build-order risk. FR-007 and the edge case at spec.md:59 correctly flag "a build-order cycle involving core and its bundled plugin," but the spec states it only as a constraint. Today system-bundles consumes a published SAML artifact; once SAML is built from source in-reactor and system-bundles switches to ${project.version}, the SAML module must build before system-bundles and must not transitively depend back on dotcms-core. This is the main implementation hazard — the plan should name where SAML sits in the reactor, not just restate the no-cycle requirement.

• ✅ Fail-closed coverage is strong. FR-005 (reject missing/mis-versioned output before image or Maven publication; upload failure fails the job), the warm-cache edge case (spec.md:56), the restore-and-publish path (spec.md:57), and the immutable-artifact-no-overwrite case (spec.md:61) together cover the replay/partial-publish failure modes that a release-wiring change most needs.

• ✅ Scope boundaries are clear and testable — no republish of 26.10.19-01, no historical-tag edits, no automatic LTS backport, no auth redesign. SC-001…SC-005 are measurable, and FR-009/SC-004 keep the imported SAML regression tests actually executing (nonzero count) rather than merely compiling, which aligns with the repo rule that unregistered integration tests silently never run.

Suggestions for the plan phase (not blocking this spec)

• The Java-variant suffix handling (Acceptance Scenario 3, line 37) is asserted but the resolved-suffix convention isn't pinned to a mechanism — worth nailing down against cicd_7-release-java-variant.yml during /speckit-plan.
• FR-006's "OSGi symbolic name and activator … must be retained" is the right invariant; a packaging assertion on Bundle-SymbolicName/Bundle-Version belongs in the test strategy, since Maven and OSGi version forms differ (edge case line 58).

Overall the spec is accurate, well-scoped, and consistent with the actual release wiring. The only concrete fix I'd ask for before sign-off is resolving the 26.10.17 reference at line 96; everything else is guidance for planning.
· branch issue-38104-saml-release-spec

[wezell]

Baseline build verification

Built the unchanged upstream SAML source at commit 2006c0fa021f21dd78db9c9d467bac6cb43e7aff in an isolated worktree using JDK 21.0.8:

./mvnw -B -ntp -Dmaven.build.cache.enabled=false clean verify

Result: BUILD SUCCESS, 26.059 seconds. Surefire reports confirm 92 tests across 11 classes, zero failures, errors, or skipped tests, including response validation, signature verification, replay-store, and authentication tests.

The baseline still declares version 26.08.21 and produces com.dotcms.samlbundle-26.08.21.jar; this is not a newly versioned release or the core integration. Nothing has been published, and no implementation source has been changed. This PR remains spec-only under the repository approval gate.

[wezell]

Clarified the requested permanent behavior: SAML must be built, versioned, referenced, and published by the normal core release using the existing publisher and MAVEN_BUNNY_RW_USERNAME / MAVEN_BUNNY_RW_PASSWORD, exactly like the other release-built plugins. No new secrets, local publish credentials, separate SAML release workflow, or manual upload may be required.

The earlier discussion of local credentials applied only to a possible one-off emergency publication; it is not a prerequisite for this automatic integration. That distinction should have been made earlier.

This push changes the spec only; the core build integration is not implemented or published yet.

[github-actions]

dotbot code review:

• Reviewer: meta/muse-spark-1.3 (medium)
• Overall: patch is correct
• New findings this run: 0
• Prior unresolved dotbot findings still relevant: 0
• Active findings total: 0

Spec-only addition with no code, build, or dependency changes; factual claims about Tika version wiring, SAML pin, coordinates, and credentials verified against the repo. No defect introduced.

Tip: comment with "/dotbot address comments" to attempt automated fixes for unresolved review threads.

_{reviewed by dotbot · meta/muse-spark-1.3 · medium}

[github-actions]

dotbot code review:

• Reviewer: ~z-ai/glm-latest (medium)
• Overall: patch is incorrect
• New findings this run: 1
• Prior unresolved dotbot findings still relevant: 0
• Active findings total: 1

Spec-only addition with no code, build, or dependency changes. Its factual claims — Tika's ${project.version} wiring, SAML's hardcoded 26.08.21 pin in osgi-base/system-bundles/pom.xml, the com.dotcms.samlbundle coordinates, and the MAVEN_BUNNY_RW_* credentials — all check out against the repository. The only issue is a minor internal version-string inconsistency in the Assumptions section.

Tip: comment with "/dotbot address comments" to attempt automated fixes for unresolved review threads.

_{reviewed by dotbot · ~z-ai/glm-latest · medium}