[Draft] GEODE-10481: Implemenation Propoal

[sboorlagadda]

For all changes:

• Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

• Has your PR been rebased against the latest commit within the target branch (typically develop)?

• Is your initial contribution a single, squashed commit?

• Does gradlew build run cleanly?

• Have you written or updated unit tests to verify your changes?

• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

[sboorlagadda]

@JinwooHwang Should we use SPDX or CyloneDX? Could you review this proposal and I want to first align on the proposal before start implementation

[sboorlagadda]

I have presented an implementation proposal using CyloneDX. Please also review the implementation proposal not only the key decision

[JinwooHwang]

Hi @sboorlagadda . I apologize for the delayed response. CycloneDX appears to be a strong and thoughtful choice. I’ll take a closer look at the proposal and follow up shortly. Thank you so much for pouring such great work into the proposal.

[JinwooHwang]

Hi @sboorlagadda,
Thanks for stepping up and putting together a solid proposal. It’s great to see this moving forward. Curious—are we envisioning SBOM generation as part of every build, or is there flexibility depending on context?
As we prepare for the Java 21+ upgrade in Geode 2.0, it's equally important to ensure readiness for Gradle 8.5. This alignment will help us avoid any build-time surprises and keep our integration smooth.

[sboorlagadda]

Hi @sboorlagadda, Thanks for stepping up and putting together a solid proposal. It’s great to see this moving forward. Curious—are we envisioning SBOM generation as part of every build, or is there flexibility depending on context? As we prepare for the Java 21+ upgrade in Geode 2.0, it's equally important to ensure readiness for Gradle 8.5. This alignment will help us avoid any build-time surprises and keep our integration smooth.

@JinwooHwang Thanks for the feedback and great questions! Let me address both points:

SBOM Generation Flexibility:
The proposal includes context-aware generation with multiple options:

• Developer builds: Optional by default (./gradlew build unchanged)
• CI/CD builds: Automatic generation via generateSbom task
• Release builds: Mandatory inclusion in distribution artifacts
• On-demand: ./gradlew generateSbom for specific needs

This approach ensures zero disruption to daily development while guaranteeing SBOM artifacts for releases and security scanning.

Gradle 8.5 & Java 21+ Readiness:
Excellent point on future-proofing! The CycloneDX plugin choice specifically addresses this:

• CycloneDX 3.0+: Already Gradle 8.x compatible with active Java 21 testing
• SPDX plugin: Currently 0.9.0 with limited Gradle 8 support roadmap

I can validate Gradle 8.5 compatibility during the Phase 1 implementation and provide a migration path if needed. The modular approach in the proposal allows us to swap plugins without changing the overall architecture.

Would you prefer I add explicit Gradle 8.5 validation as a Phase 1 deliverable, or would a compatibility assessment during implementation be sufficient?

[JinwooHwang]

Hi @sboorlagadda . Thank you for the detailed breakdown and the thoughtful consideration of both SBOM flexibility and future compatibility. Your approach strikes a good balance between developer convenience and release rigor.
Regarding Gradle 8.5 validation, I am fine with a compatibility assessment during implementation. I trust your judgment. I’m open to either path that's reasonable. Thank you.

[sboorlagadda]

Hi @sboorlagadda . Thank you for the detailed breakdown and the thoughtful consideration of both SBOM flexibility and future compatibility. Your approach strikes a good balance between developer convenience and release rigor. Regarding Gradle 8.5 validation, I am fine with a compatibility assessment during implementation. I trust your judgment. I’m open to either path that's reasonable. Thank you.

@JinwooHwang I am considering that CycloneDX is a go.

[JinwooHwang]

Hi @sboorlagadda .

Just a quick thought as we look ahead:
ASF seems to be exploring additional metadata formats for public distribution, including SBOMs. To stay ahead, it might be worth considering the following draft position:

• SBOMs needs to be automatically generated for builds at build time
• SBOMs need to be signed with the same keys used for releases, in the same way (detached signature, detached hash)
• SBOMs are expected to be static to the given release, must never be changed after release
• SBOMs need to be useful (i.e. can be parsed, machine readable by current/future tools)

Everything looks good to me. Thank you for your attention to these details-looking forward to your successful implementation.

Reference
https://cwiki.apache.org/confluence/display/COMDEV/SBOM
https://whimsy.apache.org/board/minutes/Tooling.html

[JinwooHwang]

I agree, @sboorlagadda . "SPDX plugin: Currently 0.9.0 with limited Gradle 8 support roadmap": This is a show stopper.

[sboorlagadda]

@JinwooHwang

Thank you both for the positive feedback and the excellent forward-looking guidance!

ASF SBOM Standards Alignment:
The draft position you've outlined aligns perfectly with the proposal's architecture. Let me confirm how we're already positioned:

✅ Automatic generation at build time: Phase 2-3 implementation covers this
✅ Signed artifacts: Can integrate with existing Apache release signing process
✅ Static/immutable: SBOMs generated deterministically from dependency lock state
✅ Machine readable: CycloneDX JSON format with SPDX export capability

Enhanced Implementation Plan:
Based on the ASF guidance, I'll add these elements to Phase 3 (Release Integration):

• Signing integration: Extend existing GPG signing to include SBOM artifacts
• Deterministic generation: Ensure SBOMs are reproducible across builds
• Format validation: Add compliance checks against both CycloneDX and SPDX specs
• ASF tooling compatibility: Validate with Apache Whimsy and other ASF tools

The modular approach in the proposal makes these additions straightforward without disrupting the core implementation.

Next Steps:
I'll proceed with Phase 1 implementation and incorporate the ASF requirements into the release workflow. The compatibility assessment during implementation approach works well - I'll flag any Gradle 8.5 issues early if they arise.

Thanks for the ASF context - this positions Geode to be ahead of the curve on supply chain security standards!

[JinwooHwang]

Hi @sboorlagadda .
You're very welcome. It's a well-thought-out plan that aligns seamlessly with the ASF draft, and I appreciate how you've structured it to minimize future rework once the draft takes effect. I’d also like you to know how much it means to me—and to the broader community—to have your support behind this initiative. I'm genuinely excited about the direction this project is heading. Please don’t hesitate to reach out if you need a hand—happy to support wherever it helps move things forward.