gnodet commented on PR #21990: URL: https://github.com/apache/camel/pull/21990#issuecomment-4088288500
## 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 #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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
