[jira] [Commented] (CAMEL-24724) camel-jbang: split project export and project running into reusable library modules

["Claus Ibsen (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-24724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18123965#comment-18123965 ] 

Claus Ibsen commented on CAMEL-24724:
-------------------------------------

Related: CAMEL-25388 (targeted 4.24.0) changes how the CLI reports failures (exit codes, stderr, JSON) and how camel run --background reports startup (CAMEL-25397). Its tech-debt sub-task CAMEL-25400 includes splitting Run.java; that part should build on the export/runner modules from this issue rather than duplicate them, and the runner API should return the same structured outcome (started / failed with exit code / still starting).

_Claude Code on behalf of davsclaus (Claus Ibsen)_

> camel-jbang: split project export and project running into reusable library modules
> -----------------------------------------------------------------------------------
>
>                 Key: CAMEL-24724
>                 URL: https://issues.apache.org/jira/browse/CAMEL-24724
>             Project: Camel
>          Issue Type: Wish
>          Components: camel-jbang
>            Reporter: Ricardo Martinez
>            Priority: Trivial
>
> h2. Problem
> The only Java API to export a Camel integration to a Maven project (Camel Main, Spring Boot, Quarkus) is {{{}camel-jbang-core{}}}, i.e. the Camel CLI itself. Any consumer that wants "turn these route files into a runnable project" must therefore take on picocli, jline, the plugin loader and ~3500 lines of Run that exist solely for the in-process JBang runtime.
> Affected consumers today:
>  * {{camel run --runtime=main|quarkus|spring-boot}} — exports to a temp dir, then runs Maven
>  * {{{}camel export{}}}, {{{}camel dependency list{}}}, {{camel sbom}} — all in {{camel-bang-core}}
>  * {{camel-jbang-plugin-kubernetes}} — KubernetesExport extends Export
>  * {{camel-jbang-plugin-test}} — TestInit, TestPluginExporter
>  * Camel TUI — spawns the {{camel}} binary via ProcessBuilder
>  * External tooling (e.g. Kaoto) — spawns the {{camel}} binary; breaks on every CLI option change
> h2. Goal
> Extract the export and run logic into two small, picocli-free library modules:
>  * *camel-jbang-export* — project creation: dependency discovery (via a silent KameletMain boot), pom/Dockerfile/readme generation, source file copying. API entry point: {{{}ProjectExporter{}}}.
>  * *camel-jbang-runner* — project launching: Maven build + process start per runtime.
> API entry point: {{{}ProjectRunner{}}}.
> The CLI becomes one consumer of these modules rather than the API itself. The TUI, the
> kubernetes plugin and external tooling all consume the same Java API.
> h2. Delivery
> The work is split into 7 stages, each landing as an independent non-breaking PR.
> No stage requires a consumer to change its source code unless that consumer is the subject of the stage.
> ||Stage||Subject||Key change||Jira link||
> |1|camel-jbang-core|Extract camel-jbang-export; picocli removed from export/run path|CAMEL-24727 |
> |2|camel-jbang-core|Extract camel-jbang-runner; Run.run<Runtime>() delegate to ProjectRunner|CAMEL-24726 |
> |3|camel-jbang-plugin-tui|TUI calls ProjectRunner Java API instead of spawning camel binary|CAMEL-24728 |
> |4|camel-jbang-plugin-kubernetes|KubernetesExporter extends Exporter API; thin picocli command| |
> |5|camel-jbang-plugin-test, DependencyList, SBOMGenerator|Last Export subclasses removed| |
> |6|camel-jbang-core|ExportBaseCommand deleted; packages finalised; upgrade guide| |
> |7|camel-jbang-export|DependencyResolver SPI; camel-kamelet-main becomes optional| |
> h2. Outcome per milestone
> After {*}stage 2{*}: consumers can call ProjectExporter + ProjectRunner from Java with no picocli or jline in their transitive dependency closure (camel-kamelet-main is still required).
> External tooling (e.g. Kaoto) can already depend on camel-jbang-runner to create and launch Camel applications without spawning the camel binary.
> After {*}stage 6{*}: packages are finalised and the compatibility shims removed; no further source changes are needed to consume the API.
> After {*}stage 7{*}: consumers that provide their own DependencyResolver (e.g. catalog-based static resolution) carry neither picocli nor camel-kamelet-main.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)