CAMEL-23601: camel-jbang - export layered Docker packaging for Main and Spring Boot

[Croway]

Summary

• Camel Main: Dockerfiles now use layered packaging — dependencies are copied to target/lib/ via maven-dependency-plugin:copy-dependencies, and the thin .original JAR is copied separately. On code-only changes, only the ~6 KB application layer is invalidated instead of the full 10+ MB fat JAR.
• Spring Boot: Dockerfiles use a multi-stage build with Spring Boot's jarmode=tools extract --layers to split the fat JAR into 4 Docker layers (dependencies, spring-boot-loader, snapshot-dependencies, application). Uses the new jarmode=tools syntax (replacing the deprecated jarmode=layertools removed in Spring Boot 4.1).
• Quarkus: Already uses fast-jar layered packaging. --quarkus-package-type is now deprecated and hidden.
• Runtime-specific Dockerfile templates: Dockerfile21.ftl/Dockerfile25.ftl for Camel Main, Dockerfile-spring-boot21.ftl/Dockerfile-spring-boot25.ftl for Spring Boot. Selection is driven by ExportSpringBoot.getDockerfileTemplateName().
• main-pom.ftl adds maven-jar-plugin (classpath manifest) and maven-dependency-plugin:copy-dependencies to produce layered artifacts alongside the existing fat JAR.
• Base images: all bumped to ubi9 1.24. Java 25 switched from eclipse-temurin to ubi9/openjdk-25:1.24 / ubi9/openjdk-25-runtime:1.24

JIRA: https://issues.apache.org/jira/browse/CAMEL-23601

Credit to Simon Hartl for originally raising the concern.

Test plan

• Unit tests pass (TemplateHelperTest — 23 tests, ExportTest — 69 tests)
• Exported Camel Main, Spring Boot, and Quarkus projects with camel export
• Built all three with mvn package
• Verified JARs run locally (java -jar)
• Verified thin JAR + lib/ runs for Camel Main
• Built Docker images for all three runtimes
• Ran all three Docker containers successfully

Claude Code on behalf of Federico Mariani

[davsclaus]

Nice work on the layered Docker packaging — the per-runtime approach is well designed and the upgrade guide entry is clear.

One minor consistency note: ExportQuarkus.copyDockerFiles() now always generates a fast-jar Dockerfile, but the deprecated --quarkus-package-type option is still partially functional (line 150 selects the appJar path, line 386 passes QuarkusPackageType to the POM template which sets quarkus.package.jar.type). If a user passes --quarkus-package-type uber-jar, Quarkus will build an uber-jar but the generated Dockerfile will expect fast-jar layout. Since the option is deprecated and hidden this isn't blocking, but you might consider either emitting a warning when uber-jar is passed, or removing the remaining uber-jar logic entirely.

Also a minor question: the JDK 21 Spring Boot template uses ubi9/openjdk-21:1.23 for the builder stage and ubi9/openjdk-21-runtime:1.24 for the runtime stage — are these the intended versions, or should both use the same release?

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

[davsclaus]

Minor consistency concern: the uber-jar branch is removed here, but quarkusPackageType is still used at line 150 (to select the appJar path) and line 386 (passed to the POM template as QuarkusPackageType). If someone passes --quarkus-package-type uber-jar (deprecated but accepted), Quarkus will produce an uber-jar but this Dockerfile will expect fast-jar layout.

Since the option is deprecated and hidden, this is a low-risk edge case — but worth considering a warning or removing the remaining uber-jar references entirely.

[Croway]

Good point @davsclaus , I'll update the docker base image to the latest, and use ubi9 for java25, for the quarkus part, I'll leave as it was, the property is deprecated, once we remove the property, we'll remove the uber-jar handling as well

[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-jbang-core

⚠️ Some tests are disabled on GitHub Actions (@DisabledIfSystemProperty(named = "ci.env.name")) and require manual verification:

• dsl/camel-jbang/camel-jbang-core: 1 test(s) disabled on GitHub Actions

💡 Manual integration tests recommended:

You modified dsl/camel-jbang/camel-jbang-core. 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 :: JBang :: Core
• Camel :: JBang :: MCP
• Camel :: JBang :: Plugin :: Route Parser
• Camel :: JBang :: Plugin :: TUI
• Camel :: JBang :: Plugin :: Validate
• Camel :: Launcher :: Container

---

⚙️ View full build and test results