CAMEL-23703: camel-launcher - JReleaser packaging and WinGet distribution

[ammachado]

Description

Adds JReleaser-driven package distribution for the camel-launcher module, generating installable packages for five package managers: Homebrew, SDKMAN, WinGet, Scoop, and Chocolatey.

Packaging

• jreleaser.yml configures the distribution definitions, with custom templates under src/jreleaser/distributions/camel-cli/<packager>/.
• src/jreleaser/bin/camel-package.sh is the single entry point, wrapping the JReleaser Maven plugin and mapping a release channel (stable / lts) onto a packager set, a Homebrew formula name, and the website manifests.
• The JReleaser plugin is declared with <inherited>false</inherited> and bound to no lifecycle phase, so ordinary Camel builds neither prepare nor publish packages; only the wrapper invokes its goals.
• Homebrew URLs use the search.maven.org/remotecontent redirector required by Homebrew's FormulaAudit::Urls rubocop rather than repo1.maven.org. All template URLs render through Mustache's unescaped triple-brace form, because the escaping form rewrites the = in ?filepath= as = and yields a URL brew cannot download.
• license-maven-plugin excludes cover the new .tpl templates, whose extension has no comment-style mapping (and JSON has no comment syntax at all); each exclude is documented inline in the pom.
• camel-package.sh publish is intentionally unimplemented: it exits with an error rather than defaulting a destination, because which target each packager's artifacts should be pushed to (e.g. Homebrew's own tap vs. homebrew-core) is a decision for the Apache Camel PMC, not something the script should decide on its own. The Homebrew dual-formula gap noted in jreleaser.yml is blocked on that same decision.

WinGet payload

WinGet's portable installer type creates a symlink named camel.exe, which cannot be backed by a .bat. tooling/camel-exe cross-compiles two small native bootstraps that resolve that symlink, locate camel.bat beside the target, and forward the command line. Scoop and Chocolatey need no such binary and enter through camel.bat.

• Those executables are confined to a dedicated camel-launcher-<version>-winget-bin.zip. The public -bin.zip / -bin.tar.gz no longer carry them.
• That archive is built with attach=false, so Maven never installs or deploys it. It is released through the Apache distribution archive instead: etc/scripts/stage-winget-distro.sh stages a signed, checksummed candidate under dist/dev for the vote, and etc/scripts/release-distro.sh promotes the approved bytes unchanged to dist/release.
• Promotion requires the SHA-512 published with the vote. Each candidate directory carries its own self-consistent .sha512 and .asc, so the candidate number alone cannot distinguish an approved candidate from a superseded one.
• Before generating the WinGet manifest, camel-package.sh downloads the archived payload and refuses to proceed unless it is byte-identical to the local one.
• Both archives draw their shared content from one assembly component (launcher-content.xml), so the WinGet package cannot silently diverge from the published archive.
• The installer, default-locale, and version manifests are all locally overridden and pinned to WinGet schema 1.12.0, preventing JReleaser's embedded 1.9.0 templates from producing an invalid mixed-version manifest set.

CI gates

The native-exe workflow builds twice from clean output directories and compares SHA-256 of both executables and the WinGet archive, then deploys the reactor to a throwaway repository and fails if the WinGet payload or any of its sidecars appears there. Reproducibility required pinning the PE TimeDateStamp: it is a mandatory header field that lld fills with the current wall-clock time, so both cross-compiles pass -Wl,--no-insert-timestamp. Without it every build is byte-different and the archive SHA-256 published in the WinGet manifest cannot be independently regenerated by anyone verifying the release.

The launcher JAR itself needed a separate reproducibility fix, since it is the payload inside that same archive. RepackageMojo called Spring Boot's two-argument repackage, which leaves the last-modified time null; Spring Boot's packager then stamps every entry with the current wall-clock time and falls back to an unordered BOOT-INF/lib instead of a sorted one. RepackageMojo now passes through the pinned project.build.outputTimestamp. RepackageMojoTest's three placeholder assertTrue(true) cases were replaced with real assertions over the packaged JAR's structure (BOOT-INF/classes, BOOT-INF/lib, loader classes, manifest entries), though the reproducibility fix itself remains unproven by unit test since the fixture pins each library's first-entry time regardless of the fix.

Verification

Beyond the unit tests, jreleaser:config, jreleaser:prepare and jreleaser:package were run locally in dry-run for both channels and the generated output inspected: all three WinGet manifests at schema 1.12.0, both installer architectures resolving from one archive and checksum, the Homebrew formula for the unversioned and versioned cases, and the Scoop and Chocolatey manifests. Assembly changes were checked by diffing the archive entry list before and after. The complete PackagePlanTest class passes with 31 tests and none skipped.

Open questions for reviewers

1. Does ASF policy require a package-manager-referenced artifact to be served from an apache.org host and covered by its own vote? If not, the WinGet archive could collapse back into the public one and the dist/dev staging step would go away.
2. Is the ARM64 executable necessary, given WinGet's x64 applicability on ARM64 hosts and that the bootstrap only spawns cmd.exe?

This is part 3 of the split of the original CAMEL-23703 unified Camel CLI packaging work (see #24682, #24754, #24665, #24664). It targets apache/camel main and does not depend on unmerged content from any other part of the split.

Target

• I checked that the commit is targeting the correct branch (Camel 4 uses the main branch)

Tracking

• If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

• I checked that each commit in the pull request has a meaningful subject line and body.
• I have run mvn clean install -DskipTests locally from root folder and I have committed all auto-generated changes.

AI-assisted contributions

• If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., Co-authored-by trailers) and the PR description identifies the AI tool used.

AI-assisted by Claude Code and Codex on behalf of Adriano Machado (ammachado).

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• docs
• dsl/camel-jbang/camel-launcher
• etc
• tooling/camel-exe
• tooling/maven/camel-repackager-maven-plugin

---

🔬 Scalpel shadow comparison — Scalpel: 6 tested, 0 compile-only — current: 3 all tested

Maveniverse Scalpel detected 6 affected modules (current approach: 3).

⚠️ Modules only in Scalpel (3)

• camel-etc
• camel-launcher
• docs

Changed managed plugins: org.apache.maven.plugins:maven-release-plugin

Skip-tests mode would test 6 modules (5 direct + 1 downstream), skip tests for 0 (generated code, meta-modules)

Modules Scalpel would test (6)

• camel-etc
• camel-exe
• camel-launcher
• camel-launcher-container
• camel-repackager-maven-plugin
• docs

ℹ️ Shadow mode — Scalpel observes but does not affect test execution. Learn more

💡 Manual integration tests recommended:

You modified dsl/camel-jbang/camel-launcher. The related integration tests in dsl/camel-jbang/camel-jbang-it are excluded from CI. Consider running them manually:

mvn verify -f dsl/camel-jbang/camel-jbang-it -Djbang-it-test

All tested modules (6 modules)

• Camel :: Docs
• Camel :: Etc
• Camel :: Exe
• Camel :: Launcher
• Camel :: Launcher :: Container
• Camel :: Maven Plugins :: Repackager

---

⚙️ View full build and test results

[gnodet]

Review Summary

This PR adds JReleaser-driven package distribution for the camel-launcher module, targeting five package managers (Homebrew, SDKMAN, WinGet, Scoop, and Chocolatey). The implementation is thorough and well-engineered, with exceptional attention to error handling, test coverage, and documentation of design decisions. The dual-wrapper approach (POSIX + Windows batch) with parity testing across both platforms is a notable strength.

What I Love

1. Exhaustive inline documentation -- the jreleaser.yml header and the comments throughout both wrapper scripts read like a design document. Every decision is traced back to a confirmed JReleaser behavior, and the rationale for workarounds (the Homebrew AT naming convention, the Env. template prefix vs -D properties, the JAVA_BINARY vs BINARY type) is anchored to verifiable facts. Future maintainers will thank you for this.

2. Defense-in-depth validation chain -- the scripts validate the channel, LTS line (against an allowlist with expiry-date gating), snapshot version rejection, artifact existence, and copy integrity before invoking JReleaser. The test-mode safety guards (CAMEL_PACKAGE_TEST_MODE=true required for CAMEL_PACKAGE_TEST_VERSION) prevent accidental production skips. This level of rigor is uncommon in release tooling scripts.

3. Test architecture -- the PackagePlanTest uses nested @DisabledOnOs(WINDOWS) / @EnabledOnOs(WINDOWS) classes to exercise both wrappers on their native platform, with mvn stubs to isolate JReleaser invocation from the plan logic. The synthetic LTS fixture (supportEnds: "9999-12-31") decouples tests from real LTS calendar dates. The test that deliberately reads the real supported-lts.yml for 4.22 catches accidental deletions. Thoughtful design.

Findings

Important

Scoop autoupdate hash URL may 404 (manifest.json.tpl, autoupdate.hash.url):

The Scoop manifest configures autoupdate hash verification as:

"hash": {
    "url": "$url.sha512"
}

I verified that Maven Central does not publish .sha512 sidecar files for camel-launcher-4.21.0-bin.zip (returns HTTP 404). Only .sha1 and .md5 are present. This means that when Scoop's checkver -u runs, it will fail to fetch the hash for the new version, breaking auto-update.

Options:

• Use "url": "$url.sha1" (universally available on Maven Central)
• Omit the hash block entirely (Scoop will download the artifact and compute the hash itself during checkver -u)
• Verify that the 4.22.0 release process (via Sonatype Central Portal) will generate .sha512 sidecar files for classified artifacts -- if it will, this is fine for future releases but needs documentation noting it won't work for retroactive verification of pre-4.22 artifacts

Could you confirm which approach is correct here? The Sonatype Central Portal's SHA-512 requirement may apply differently to classified artifacts.

Suggestions

[Suggestion] formula_opt_bin is Homebrew private API (formula.rb.tpl, line in def install):

CAMEL_FALLBACK_JAVA: "#{formula_opt_bin("openjdk")}/java"

Homebrew's Ruby API documentation marks formula_opt_bin as private API ("This method is part of a private API. This method may only be used in the Homebrew/brew repository"). While JReleaser's own default JAVA_BINARY template uses this same pattern (so it is a well-established convention), it could break without warning in a future Homebrew release.

The public-API equivalent would be:

CAMEL_FALLBACK_JAVA: "#{Formula["openjdk"].opt_bin}/java"

This is not blocking since JReleaser uses this pattern widely and Homebrew has maintained the method for years, but worth being aware of.

[Nit] Unquoted $SNAPSHOT_PATTERN_ARG in camel-package.sh (line ~859):

  $SNAPSHOT_PATTERN_ARG \

The intentional word-splitting (empty string becomes no argument) is correct behavior, but ShellCheck will flag this. A brief comment like # shellcheck disable=SC2086 -- intentional: empty var must vanish would prevent future contributors from "fixing" it.

[Nit] WinGet manifest schema version (installer.yaml.tpl):

# yaml-language-server: $schema=https://aka.ms/winget-manifest.installer.1.9.0.schema.json
ManifestVersion: 1.9.0

Declaring ManifestVersion: 1.9.0 is fine and forward-looking. Just noting it should be verified against what the winget-pkgs community repository currently accepts, since newer schema versions sometimes require fields that older winget validate versions do not enforce.

Critical

None -- nice work!

Questions

[Question] Network dependency in test-mode Homebrew formula patching (camel-package.sh, lines ~912-960):

The test-mode code downloads a known-good release from Maven Central to patch the generated formula. This is a clever approach that exercises a real brew install end-to-end. However, it introduces a hard network dependency -- if Maven Central is unreachable during CI, the packaging validation fails even though the packaging logic itself is correct.

Is this expected to run in CI, or only in manual pre-release validation? If CI, would it make sense to have a fallback (e.g., skip the patch with a warning when Maven Central is unreachable, since the formula content correctness is already validated by the non-network tests)?

Overall

This is a high-quality, well-documented piece of release engineering work. The attention to platform parity, error handling, and test isolation is impressive. The Scoop autoupdate hash URL is the one item I would want confirmed before merge. Everything else is solid and ready.

Claude Code on behalf of gnodet -- AI-generated review

[gnodet]

Re-review: CAMEL-23703 JReleaser package generation (14 new commits)

This re-review covers the 14 new commits added since the initial review. Every finding from the previous review has been addressed, and the new changes represent a significant improvement in both design and robustness.

What stands out in this iteration

Vote-digest candidate promotion (release-distro.sh + stage-winget-distro.sh): The three-layer verification chain — vote-email digest match, .sha512 self-consistency check, GPG signature verification — is a genuinely strong security design. The insight that the candidate number alone cannot distinguish the approved candidate from a superseded one (each RC carries its own self-consistent .sha512 and .asc) is non-obvious and the digest-based approach solves it cleanly. The test coverage in WingetDistroScriptsTest validates all three failure modes (tampered payload, wrong candidate, missing digest) with fully stubbed dependencies.

Shared assembly content (launcher-content.xml): Extracting the common archive content into a shared component descriptor and having both bin.xml and winget-bin.xml reference it is the right structural choice. The test bothArchivesShareOneContentDefinition ensures this invariant survives future refactoring — a detail that makes this more than just "clean code."

CI defense-in-depth for Maven non-deployment: The CI step that deploys to a throwaway local repo and then fails if any *-winget-bin.zip* file appears is an effective guard against accidental Maven attachment. Combined with attach=false in the assembly execution, this provides two independent layers of protection.

Batch wrapper removal: The removal of camel-package.bat was clean — no remaining references anywhere in the diff, and install.ps1 was properly updated to use camel.bat (architecture-neutral) instead of the native executables for the public archive.

Findings

See inline comments. No blocking issues found.

Scanner coverage

• shellcheck: ran on all .sh files. Findings on pre-existing code in release-distro.sh (unquoted variables, [ -o ] usage); the new code added by this PR uses proper quoting throughout. One informational note on stage-winget-distro.sh (SC2015: A && B || C) which is safe here since usage exits.
• gitleaks: ran on all release scripts — no leaks found.
• semgrep, pmd, ast-grep: available but not run (no Java source files with sufficient complexity to warrant it for this review; the test files are well-structured).

Previous review items — status

Previous finding	Status
Scoop autoupdate hash URL may 404	Fixed — hash key removed from autoupdate block; Scoop computes SHA-256 itself. Test scoopAutoupdateComputesSha256RatherThanReusingTheSha1Sidecar enforces this.
formula_opt_bin is Homebrew private API	Acknowledged — still present (was a suggestion, not blocking).

Claude Code on behalf of gnodet — AI-generated review

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

[davsclaus]

Claude Code on behalf of Claus Ibsen (davsclaus)

Nice work on this PR — the packaging infrastructure is thorough, well-tested, and security-conscious. A few observations:

Findings

Minor

1. Wildcard import in PackagePlanTest.java — import java.util.*; will likely be expanded by impsort:sort, generating an uncommitted change that fails CI. See inline comment.

2. supported-lts.yml only lists 4.22 — the file only contains line "4.22". Since this drives package distribution (not security patches), this seems intentional, but worth confirming it's not an omission of 4.14/4.18.

Questions

• The publish subcommand in camel-package.sh returns exit 2 with "not yet implemented (Phase 5)". Is there a follow-up task tracked?
• The jreleaser.yml notes a "KNOWN GAP" about producing both unversioned and versioned Homebrew formulae from a single --channel stable --lts-line X.Y run. Is a follow-up task filed?
• The jreleaser-plugin-version (1.25.0) is declared as a module-level property rather than centralized. Since <inherited>false</inherited> is set this works fine, but is that intentional?

Strengths

• Thorough test coverage: 31+ tests in PackagePlanTest, plus WingetDistroScriptsTest with stubbed svn/gpg/curl
• Security-conscious: attach=false prevents WinGet ZIP from reaching Maven Central; vote-approved SHA-512 digest guards against promoting a superseded candidate
• CI reproducibility gates (build twice, compare SHA-256) and deploy verification
• Clean assembly refactoring via shared launcher-content.xml with test invariants enforcing it
• Correct symlink resolution in camel.c with proper fallback
• Upgrade guide and release guide updates present

This review covers project rules and conventions. It does not replace specialized review tools such as CodeRabbit, Sourcery, or SonarCloud.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

[gnodet]

New commit d6ea308 (make the repackaged launcher JAR reproducible) looks good — clean follow-up to the PE timestamp pinning.

What works well:

• Root cause is clearly explained in the commit message: the 2-arg Repackager.repackage leaves last-modified null, which causes both wall-clock entry timestamps and insertion-order BOOT-INF/lib ordering. Using the 3-arg overload with parseOutputTimestamp fixes both at once.
• Using MavenArchiver.parseBuildOutputTimestamp is the canonical Maven API — handles ISO-8601, epoch-seconds, single-char disable convention, and SOURCE_DATE_EPOCH fallback correctly.
• Good defensive design: parseOutputTimestamp returns null when reproducible output is not configured, preserving backward compatibility.
• Thorough tests cover all four edge cases (ISO, epoch, unset/disabled, malformed).
• The testInvalidOutputTimestampFailsLoudly test documents an important invariant — a malformed value must fail rather than silently degrading to non-reproducible output.
• Workflow enhancement (diffing unzip -v output) is a nice diagnostic improvement for distinguishing content changes from timestamp changes.

LGTM ✅

Claude Code on behalf of gnodet — AI-generated review

[gnodet]

New commit 422afeb (replace placeholder repackager tests with real ones) is a significant quality improvement — well done.

What's great:

• The old tests were all `assertTrue(true, "Placeholder test")` — now they create actual repackaged JARs and verify real invariants:
  • Structure: BOOT-INF/classes, BOOT-INF/lib, root loader classes all present
  • Manifest: Main-Class = JarLauncher, Start-Class = CamelLauncher (swapping these produces a silently broken JAR)
  • Dependency filtering: compile-scope included, test-scope excluded, native exe excluded
  • Reproducibility: two runs produce byte-identical output — the most important invariant given this PR's theme
• The `writeJar()` fixture uses fixed entry times (`FIXED_ENTRY_TIME`) so the test fixture itself can't introduce the non-determinism the reproducibility test is checking for — good attention to detail.
• The workflow fix (installing `camel-repackager-maven-plugin` before the launcher build) is a real correctness improvement — without it, changes to the plugin in the same PR would be silently ignored because Maven resolves the plugin from the snapshot repo.
• Enhanced diagnostic: on mismatch, now also unpacks the launcher JAR from both builds and diffs entries one level deeper.
• Using `protected` instead of `private` on mojo fields is the standard Maven plugin testing pattern.

LGTM ✅

Claude Code on behalf of gnodet — AI-generated review

[ammachado]

Claude Code on behalf of Adriano Machado (ammachado)

Replying to @davsclaus's review:

• supported-lts.yml only listing 4.22 — not an omission. This file gates which --lts-line values the new CLI packaging pipeline in this PR accepts. 4.14/4.18 were never packaged through this pipeline (it didn't exist), so there's nothing to omit; 4.22 is simply the first line eligible.
• jreleaser-plugin-version as a module-level property — intentional. jreleaser-maven-plugin is used in exactly this one pom, and the module already declares other single-use version properties locally (maven-version, plexus-*-version, etc.) rather than centralizing. <inherited>false</inherited> is correctly set alongside it.
• publish / Homebrew dual-formula gap — reworded both comments (camel-package.sh, jreleaser.yml, and the SDKMAN release-notes.md note) to drop the "Phase 5" references, which were only ever tracked in local notes, not a public tracker. The actual blocker: where each packager's artifacts get published (e.g. Homebrew to this project's own tap vs. homebrew-core) is a decision for the Apache Camel PMC. The Homebrew dual-formula gap is blocked on that same decision, not a separate follow-up — the comments now say so explicitly.
• Wildcard import — already fixed prior to this review; replied inline.

Pushed as two commits: batch-mode (-B) fix for the exe-build CI steps, and the comment rewording above.

[gnodet]

New commit 1f0f9e17f602 reviewed — good cleanup. Replacing the opaque "Phase 5" references with the actual blocking reason (PMC publish-destination decision) makes the codebase much more readable for contributors who weren't part of the original planning.

Comment/documentation-only changes — prior approval still applies.

Claude Code on behalf of gnodet — AI-generated review

[ammachado]

Status update on the pieces of CAMEL-23703:

Component	Status
Java runtime discovery for camel.sh/camel.bat	Merged (#24664)
Native camel.exe bootstrap (Windows)	Merged (#24665)
Cross-compile camel.exe for x64/arm64	Merged (#24754)
Website installer scripts (install.sh/install.ps1) + release manifests	Merged (#24682)
JReleaser packaging (Homebrew, SDKMAN, WinGet, Scoop, Chocolatey)	Open, in review (this PR)
Package-native validation CI (installs/uninstalls each generated package and smoke-tests it)	Prepared; PR will follow once this one merges

Not yet started:

• Actual publishing to the package managers. Everything above only prepares/packages the artifacts locally; nothing pushes a release to Homebrew, SDKMAN, WinGet, Scoop, or Chocolatey yet. This needs a PMC decision on publish destinations first, e.g. whether Homebrew formulae go to this project's own tap or to homebrew-core, since that decision shapes how publishing gets wired up. It also blocks producing both the unversioned and versioned Homebrew formula from a single release.
• Making install.sh/install.ps1 reachable at camel.apache.org. The scripts are done and tested, but nothing serves them yet, so curl -fsSL https://camel.apache.org/install.sh doesn't resolve. That requires a change in the camel-website repo; the tracking issue there (Add Install scripts for Camel Launcher camel-website#1487) is still open with no PR against it.

Claude Code on behalf of Adriano Machado (ammachado)

[davsclaus]

LGTM