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

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

Hi [~ricmarti], CAMEL-25388 is now done (resolved for 4.24.0), so the hold I 
asked for on 2026-10-06 is lifted and this can continue.

Are you still working on this? Stages 1 (CAMEL-24727) and 2 (CAMEL-24726) are 
In Progress, but I can't find any PRs for them yet. If you don't have time for 
it, I'm happy to take it over so it gets into the 4.24 release. Please let me 
know either way.

_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
(v10.3.26#10030026)

Reply via email to