CAMEL-23703: camel-launcher - cross-compile native camel.exe for x64 and arm64 via llvm-mingw#24754
Merged
davsclaus merged 5 commits intoJul 19, 2026
Conversation
Contributor
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
ammachado
force-pushed
the
CAMEL-23703-native-exe-crosscompile
branch
3 times, most recently
from
July 15, 2026 22:41
fb64721 to
85b8ceb
Compare
Contributor
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 649 tested, 27 compile-only — current: 3 all testedMaveniverse Scalpel detected 676 affected modules (current approach: 3).
|
ammachado
marked this pull request as ready for review
July 16, 2026 02:32
gnodet
approved these changes
Jul 16, 2026
gnodet
left a comment
gnodet
left a comment
Contributor
There was a problem hiding this comment.
Clean infrastructure migration. Moves the native camel.exe build from MSVC (Windows-only, x64-only) to clang/llvm-mingw (any host OS, x64 + arm64), and all CI is green.
What looks good:
- SHA256-pinned toolchain setup — the
setup-llvm-mingwcomposite action pins version20260616with SHA256 verification before extracting, preventing supply-chain attacks on the toolchain itself - Profile activation migration — from OS-based (
<family>windows</family>) to property-based (camel.exe.build=true), correctly wired through-Preleasein rootpom.xml - CI restructured well — Linux-based cross-compilation for the build, with a separate
camel-exe-windows-smokejob that downloads the artifact and smoke-tests on actual Windows - Release gate preserved —
maven-enforcer-pluginchecks for bothcamel-x64.exeandcamel-arm64.exebefore packaging - Jenkinsfile.deploy adds a
Verify llvm-mingwstage that fails loudly if cross-compilers aren't on PATH - Comprehensive documentation — upgrade guide explains the naming change (
camel.exe→camel-x64.exe/camel-arm64.exe), release guide adds llvm-mingw as a prerequisite, all READMEs updated CamelExeBootstrapTestcorrectly auto-selects the architecture-appropriate exe (os.arch→x64/arm64)RepackageMojo.includeArtifact()comment and test updated to reference both exe files
CI status: All green — camel-exe (1m), camel-exe-windows-smoke (1m), camel-launcher-native (10m), build (17) (2h25m), build (25) (2h11m) all passed.
No issues found.
Reviewed with Claude Code on behalf of @gnodet. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.
davsclaus
reviewed
Jul 16, 2026
davsclaus
left a comment
davsclaus
left a comment
Contributor
There was a problem hiding this comment.
Review: CAMEL-23703 cross-compile native camel.exe for x64 and arm64
Well-structured PR with comprehensive documentation updates. All CI checks pass. One infrastructure-coordination concern.
Confirmed Issues
1. Jenkinsfile.deploy: snapshot deploys will require llvm-mingw on Jenkins agents (Medium)
Adding -Dcamel.exe.build=true to MAVEN_PARAMS means every snapshot deploy on main, camel-4.18.x, and camel-4.14.x will activate the build-native-exe profile in tooling/camel-exe/pom.xml. The exec-maven-plugin invocations run at generate-test-resources phase — this phase executes even with -Dquickly and -DskipTests. If the ASF Jenkins agents don't have x86_64-w64-mingw32-clang and aarch64-w64-mingw32-clang on PATH, all snapshot deploys break.
The added Verify llvm-mingw stage provides a clear early error, which is good. But this is a new infrastructure prerequisite that didn't exist before.
Questions
1. Are the ASF Jenkins agents already provisioned with llvm-mingw?
The GitHub Actions workflow self-installs via .github/actions/setup-llvm-mingw/, but the Jenkinsfile assumes the toolchain is pre-installed. The release-guide.adoc update documents this as a prerequisite. If the agents aren't ready, should the Jenkinsfile changes be deferred to a follow-up PR merged after infrastructure setup?
2. Dual exe compilation in CI workflow (minor)
The exe is compiled twice in the GitHub Actions workflow: once in the camel-exe job and again in the camel-launcher-native job. Not incorrect, but the camel-launcher-native job could potentially reuse the artifact from camel-exe to save CI minutes.
No Issues Found
- Git history: Builds on
d603bdd(original camel.exe) — no prior intentional work reverted; this evolves the same feature. - Tests: Properly updated. Bootstrap test remains
@EnabledOnOs(WINDOWS). Launcher IT drops the OS restriction (correct for cross-compiled file-existence checks). - Documentation: Upgrade guide documents the
camel.exe→camel-x64.exe/camel-arm64.exerename. Release guide documents llvm-mingw prerequisite. All READMEs updated. - Security: SHA256 pinning for the llvm-mingw download.
- Attribution: Follows project rules.
- Release profile:
camel.exe.build=trueadded to rootreleaseprofile — correct.
This review covers project rules and conventions. It does not replace specialized tools like CodeRabbit, Sourcery, or SonarCloud.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
oscerd
reviewed
Jul 16, 2026
oscerd
left a comment
oscerd
left a comment
Contributor
There was a problem hiding this comment.
The migration itself looks solid — genuine dual-target build (x86_64-w64-mingw32-clang → camel-x64.exe and aarch64-w64-mingw32-clang → camel-arm64.exe, both attached with separate classifiers and required by the enforcer), the llvm-mingw toolchain is version-pinned and SHA-256-verified over HTTPS with set -eo pipefail, all actions/* are SHA-pinned with persist-credentials: false, no hardcoded secrets, and -municode/wmain is correct. CI (camel-exe, windows-smoke, launcher-native) is green.
Two things worth resolving before merge, both non-code:
- Release/deploy prerequisite —
Jenkinsfile.deploysets-Dcamel.exe.build=trueand thebuild-native-exeexec runs atgenerate-test-resources(even with-DskipTests), so if the ASF Jenkins agents don't havex86_64-w64-mingw32-clang/aarch64-w64-mingw32-clangon PATH, snapshot deploys on main (and the 4.18.x/4.14.x branches the Jenkinsfile gating anticipates) would break. The new loud-fail "Verify llvm-mingw" stage mitigates it, but the "are the agents provisioned?" question you raised looks still-open. - arm64 is compiled but not runtime-smoke-tested (no Windows-arm64 CI runner) — acceptable given the shared ~100-line source, just noting the residual risk.
Reviewed with Claude Code on behalf of Andrea Cosentino. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.
Contributor
Author
|
On the "are the ASF Jenkins agents provisioned with llvm-mingw?" question (thanks @davsclaus, @oscerd): The download/verify logic and the pinned version + hash now live in one shared script, I left the arm64 runtime-smoke gap as-is, since there's no Windows-arm64 runner; the source is shared with x64, which is smoke-tested. Claude Code on behalf of @ammachado |
davsclaus
approved these changes
Jul 16, 2026
Contributor
Author
|
On the dual exe compilation (thanks @davsclaus): I looked at reusing the The real cost in that job was While in there I also moved both exe jobs off mvnd to plain One tradeoff worth calling out: the launcher packaging check now trusts Apache snapshots for its unchanged upstream modules instead of building them from source. Since this workflow only triggers on Claude Code on behalf of @ammachado |
ammachado
force-pushed
the
CAMEL-23703-native-exe-crosscompile
branch
from
July 16, 2026 20:58
35b9a33 to
7f3fb9d
Compare
davsclaus
requested changes
Jul 17, 2026
davsclaus
approved these changes
Jul 17, 2026
davsclaus
force-pushed
the
CAMEL-23703-native-exe-crosscompile
branch
2 times, most recently
from
July 17, 2026 21:00
ca16036 to
a64efaa
Compare
gnodet
approved these changes
Jul 17, 2026
gnodet
left a comment
gnodet
left a comment
Contributor
There was a problem hiding this comment.
Claude Code review on behalf of gnodet
Re-review — rebased with CI refinements
Good refinements since my last review. The new commits add:
1. Self-provisioning llvm-mingw in Jenkinsfile.deploy ✅
Setup llvm-mingwstage gated tomainandcamel-4.22.x— older LTS branches deploy without native exe- Reuses the shared
install-llvm-mingw.shscript (single source of truth for pinned version + SHA256) - Falls back to agent-provided toolchain if already on PATH, otherwise downloads into
$HOME/.cache/llvm-mingw - Verification step confirms both cross-compilers are present before proceeding
2. Plain mvn for small reactors ✅
- Explains rationale in
install-mvnd/action.ymlcomment: mvnd's daemon cold-start timeout adds a flaky failure mode for small reactors with no parallelism benefit camel-exeandcamel-launcher-nativejobs use plainmvnappropriately
3. Snapshot dependency resolution for launcher-native ✅
- Uses
-P apache-snapshotswithout-amto resolve upstream modules from Apache snapshot repo - Smart sentinel check: verifies
camel-launchersnapshot metadata exists before starting, failing early with a clear message instead of a deep Maven resolution error - Significantly reduces build scope (handful of modules vs full launcher reactor)
4. Branch gating ✅
- Native exe build gated to
mainandcamel-4.22.xin both Jenkinsfile.deploy and the workflow comments - Older LTS branches continue deploying snapshots normally without the native build
All the infrastructure decisions are well-reasoned and documented with inline comments. CI is running. LGTM.
davsclaus
force-pushed
the
CAMEL-23703-native-exe-crosscompile
branch
from
July 18, 2026 05:59
a64efaa to
ae9762d
Compare
…and arm64 via llvm-mingw Replace the MSVC/Windows-only native exe build with a host-OS-independent cross-compile using clang from the llvm-mingw toolchain (pinned, SHA256-verified). Produces bin/camel-x64.exe and bin/camel-arm64.exe from any host OS, activated by -Dcamel.exe.build=true or -Prelease. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…deploys Extract the llvm-mingw download/verify logic into a shared install script (.github/actions/setup-llvm-mingw/install-llvm-mingw.sh) so the pinned version and SHA256 live in one place, used by both the GitHub Actions composite action and Jenkinsfile.deploy. Jenkinsfile.deploy now reuses an agent-provided toolchain when the cross-compilers are already on PATH, and otherwise downloads the pinned, SHA256-verified copy into a persistent cache. This removes the requirement to pre-provision llvm-mingw on the ASF Jenkins agents raised in PR review. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…e reactor The camel-exe job builds only a handful of modules, so the mvnd daemon adds no parallelism benefit and exposed a flaky daemon cold-start timeout. Run plain mvn there; keep mvnd for camel-launcher-native, whose -am reactor pulls in the broader component tree. Document the guidance in install-mvnd. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…drop mvnd Remove -am from the camel-launcher-native job so it builds only the listed modules and resolves the launcher's upstream modules as the current version's snapshot from Apache snapshots, instead of rebuilding the whole launcher reactor from source. Add a preflight that fails early with a clear message if that snapshot tree is not published yet, using camel-launcher (the terminal module, deployed after its dependencies) as the sentinel. Switch the job to plain mvn: with -am gone the reactor is only a few modules, so the mvnd daemon buys no parallelism and its cold-start was a flaky failure mode. Pin all jobs to Java 25 to stay aligned with the highest producer of the snapshots and avoid class-version mismatches on the compile classpath. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…and camel-4.22.x The snapshot-deploy pipeline runs on main, camel-4.18.x and camel-4.14.x. The native camel.exe cross-compile only exists on main (and the upcoming camel-4.22.x LTS), so the llvm-mingw setup and -Dcamel.exe.build no longer run on the older LTS branches; those branches keep deploying their snapshots without the native build. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ammachado
force-pushed
the
CAMEL-23703-native-exe-crosscompile
branch
from
July 19, 2026 05:39
ae9762d to
d5b1abc
Compare
davsclaus
approved these changes
Jul 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Claude Code on behalf of ammachado
Description
This PR splits the native Windows executable cross-compile work out of the larger CAMEL-23703 package distribution branch.
It replaces the Windows/MSVC-only
camel.exebuild with a host-independent clang/llvm-mingw flow and publishes separate launcher executables for Windows x64 and Windows ARM64:bin/camel-x64.exebin/camel-arm64.exeThe release profile now activates
camel.exe.build, and the launcher module copies both classifiedcamel-exeartifacts into the distribution when that property is enabled. The native executable workflow is renamed from the old Windows-only workflow tocamel-launcher-native-exe.yml.The native bootstrap uses a wide-character
wmainentry point to preserve Unicode command lines, so both llvm-mingw compile invocations pass-municode.Toolchain provisioning
The llvm-mingw download/verify logic (pinned version + SHA256) lives in a single shared script,
.github/actions/setup-llvm-mingw/install-llvm-mingw.sh, used by both the GitHub Actions composite action andJenkinsfile.deploy. The CI snapshot-deploy pipeline reuses an agent-provided toolchain when the cross-compilers are already onPATH, and otherwise downloads the pinned, SHA256-verified copy into a persistent cache. This removes the need to pre-provision llvm-mingw on the ASF Jenkins agents. A local-Preleasebuild still requires the toolchain onPATH(documented in the release guide).The native
camel.exebuild is scoped to the branches that actually carry the launcher: theSetup llvm-mingwstage and-Dcamel.exe.build=trueonly run onmainand the upcomingcamel-4.22.xLTS. The older LTS branches (camel-4.18.x,camel-4.14.x) continue to deploy their snapshots without the native build.Target
mainbranch)Tracking
Apache Camel coding standards and style
mvn clean install -DskipTestslocally from root folder and I have committed all auto-generated changes.Formatter verification was run locally with
mvn formatter:format impsort:sortand passed. Full build/test verification is intentionally deferred to CI/PR for this split.AI-assisted contributions
Co-authored-bytrailers) and the PR description identifies the AI tool used.