CAMEL-23192: Adds missing dockerfiles

[mcarlett]

No description provided.

[mcarlett]

IT tests are in #21987

[gnodet]

LGTM. Clean and straightforward change.

Summary of changes:

• Adds three missing Quarkus Dockerfile variants (Dockerfile.jvm, Dockerfile.legacy-jar, Dockerfile.native-micro) as resources, aligning with the standard set that Quarkus projects provide.
• Updates ExportQuarkus.copyDockerFiles() to copy all four Dockerfile variants instead of just Dockerfile.native.
• Bumps the UBI base image comment in Dockerfile.native from 9.5 to 9.6 (the FROM line already referenced 9.6).

Review notes:

• The List import is already present in ExportQuarkus.java, so no new import is needed.
• The null check on the InputStream (if (is != null)) is a good defensive practice.
• The Dockerfiles follow the standard Quarkus template patterns (UBI9 base images, proper layering, correct entry points).
• The base class Export.copyDockerFiles() creates the src/main/docker directory and writes a generic Dockerfile; the override correctly calls super first, then adds the Quarkus-specific variants. No conflict.
• The Dockerfile.native comment fix (9.5 -> 9.6) is a minor correctness improvement.

One minor observation (non-blocking): the PR body is empty. Adding a brief description referencing the JIRA issue would help future readers, but this is cosmetic.

[jamesnetherton]

Are these Dockerfiles up-to-date?

If you generate an app with the latest Quarkus releases you'll see a base image of registry.access.redhat.com/ubi9/openjdk-21-runtime:1.24.

[jamesnetherton]

Also FWIW - I hacked up a script recently to fetch the latest Dockerfiles. It could perhaps be adapted for this project.

https://github.com/apache/camel-quarkus-examples/blob/camel-quarkus-main/refresh-dockerfiles.sh

[mcarlett]

thanks @jamesnetherton I get those version for the current LTS (3.27), do we want latest?

[jamesnetherton]

do we want latest?

I think so because 3.33 is about to become the latest LTS stream.

[mcarlett]

done, I kept jdk21 (the latest dockerfile are using jdk25) but I updated it with the latest tag available, thanks!

[squakez]

I think we remove those resources on purpose. The goal was to harmonize the dockerfiles coming off the export regardless the runtime.

[squakez]

The cleaning work was in #18981

[mcarlett]

thanks @squakez I didn't know that in the past there were those files, but so I'm wondering why if we generate the Quarkus application using quarkus-maven-plugin (create goal) those file are generated. Moreover the currently generated Dokerfile is not working, it is like:

COPY --chown=185 target/cheese-0.0.1.jar /deployments/

# Uncomment to expose any given port
# EXPOSE 8080
USER 185
# Uncomment to provide any Java option
# ENV JAVA_OPTS=""
ENV JAVA_APP_JAR="/deployments/cheese-0.0.1.jar"

ENTRYPOINT [ "/opt/jboss/container/java/run/run-java.sh" ] 

but the jar it uses is not a fat-jar and it doesn't work. So it is a little bit misleading to have this resource

[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 build-all, build-dependents, 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.

[davsclaus]

yeah the docker files was intented to be like what you get if you create a new quarkus project from code.quarkus.io

SB does not come with that. If we can make a docker file for CSB then that is good, if not maybe we then only make these files exported with quarkus.

[claudio4j]

For the quarkus runtime, isn't best to let the quarkus-container-image-jib extension to take care of it ? It doesn't require a Dockerfile.

[squakez]

The idea of harmonizing the docker for all runtimes was to simplify the execution on containers/k8s regardless of the runtime. If we want to have some difference and also support all the formats required by Quarkus, I think we can create an additional folder (ie, docker/quarkus) where we put the files expected by this runtime. In this way we can easily identify as docker as the files if you want to run "the camel way" and docker/quarkus if you want to run "the quarkus way".

[gnodet]

Analysis of Dockerfile generation approaches

There are several ways to address the broken Quarkus Dockerfile situation. Here's a summary:

Option 1: Fix the generic Dockerfile to work per runtime

Generate a single Dockerfile with runtime-specific content by templating it.

• Pros: Simple, one file, no confusion
• Cons: Can't cover all Quarkus modes (JVM vs native) in one file

Option 2: Subfolder compromise (docker/quarkus/)

Keep generic Dockerfile, add Quarkus-specific ones under a subfolder.

• Pros: Backward compatible, unified story stays intact
• Cons: Confusing — which Dockerfile should I use?

Option 3: Add Quarkus Dockerfiles directly (current PR approach)

Put all Quarkus Dockerfiles alongside the generic one.

• Pros: Matches code.quarkus.io output, familiar to Quarkus users
• Cons: Undoes harmonization from chore(dsl): harmonize Dockerfile text #18981

Option 4: Use quarkus-container-image-jib (no Dockerfile)

Rely on Quarkus build extension instead.

• Pros: No Dockerfiles to maintain
• Cons: Different workflow, doesn't help users who need Dockerfiles for custom CI/CD

Option 5: Runtime-specific Dockerfiles only (drop the generic one)

Each runtime generates its own correct Dockerfile(s).

• Pros: Every Dockerfile works
• Cons: Breaks harmonization, more to maintain

Option 6 (recommended): Runtime-aware default Dockerfile + optional extras

The default Dockerfile is runtime-aware and works out of the box (JVM mode). For Quarkus, also generate Dockerfile.native and Dockerfile.native-micro since those are alternate build modes.

• Pros: The main Dockerfile always works. Extra files are clearly for alternate build modes, not duplicates. No confusion. Each runtime gets exactly what it needs.
• Cons: Need per-runtime templates.

No new CLI args are needed — the export already knows the runtime. The base Export.copyDockerFiles() generates a working Dockerfile for the current runtime, and ExportQuarkus additionally copies the native variants. This is essentially what the current PR does, but with the generic Dockerfile also being Quarkus-aware (JVM mode) instead of broken.

I've pushed a commit restructuring the implementation along these lines.

[mcarlett]

thanks @gnodet , @squakez WDYT?

[squakez]

thanks @gnodet , @squakez WDYT?

It seems an AI generated content, not sure it has all the context to define an action plan. As we have discussed privately a few days ago, IMO, we should have 2 layers.

1. Camel dockerfiles, which all have a similar outset (ie, if the quarkus one does not work, we must fix adding a quarkus fat-jar, or a similar solution)
2. Quarkus dockerfiles, which have a specific Quarkus runtime compatible format.

[gnodet]

Reworked the approach based on @squakez's 2-layer suggestion:

Layer 1 (Camel Dockerfile): Configure Quarkus to produce an uber-jar (quarkus.package.jar.type=uber-jar in the POM template), so it outputs a single fat jar just like camel-main and Spring Boot. The generic Dockerfile template works as-is — no runtime-specific Dockerfile needed for JVM mode.

Layer 2 (Quarkus Dockerfiles): Copy Dockerfile.native and Dockerfile.native-micro for users who want native compilation.

Removed Dockerfile.jvm and Dockerfile.legacy-jar since the generic Dockerfile now covers JVM mode.

[mcarlett]

Layer 1 (Camel Dockerfile): Configure Quarkus to produce an uber-jar (quarkus.package.jar.type=uber-jar in the POM template), so it outputs a single fat jar just like camel-main and Spring Boot. The generic Dockerfile template works as-is — no runtime-specific Dockerfile needed for JVM mode.

is it fine to propose uber-jar as default solution? currently on Quarkus is not the default proposed solution, thanks @gnodet

[gnodet]

We could offer both packaging options — fast-jar (Quarkus default) and uber-jar — via a flag on camel jbang export (e.g. --packaging=uber-jar or --packaging=fast-jar).

Each has trade-offs:

• fast-jar (Quarkus default): better startup time, better Docker layer caching (dependencies in separate layers), recommended by Quarkus community. Requires a Quarkus-specific Dockerfile that copies the quarkus-app/ directory structure.
• uber-jar: single fat jar, simpler generic Dockerfile that works across all runtimes (main, Spring Boot, Quarkus). Easier for getting started / prototyping.

The question is which should be the default. Thoughts? Should we default to fast-jar to respect Quarkus conventions, or uber-jar for simplicity/consistency with the other runtimes?