[
https://issues.apache.org/jira/browse/CAMEL-24724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18129076#comment-18129076
]
Claus Ibsen commented on CAMEL-24724:
-------------------------------------
Moved here from CAMEL-25400 (the tech debt cleanup of CAMEL-25388), as they
belong to the run/export split:
# The code that run and export both have: {{doExport}} and the Maven invocation.
# The shared {{.camel-jbang}} work directory.
# Split {{Run.java}} (about 3,950 lines: the options it shares with Export, the
classification of the source files, one launcher per runtime, the background
supervisor), and move {{camel harden}} onto {{LlmClient}}.
Already done in CAMEL-25400, for 4.24.0: {{ChildProcess}} (the processes Maven
starts stop with the CLI) and {{MavenCommand}} (one lookup of the Maven
wrapper) in #27933, and {{CliRunner}} (new instances of the commands for each
run, in one JVM) in #27962.
For stage 2 (CAMEL-24726): PR #28171 (CAMEL-25832) changes {{runCamelMain}},
{{runQuarkus}} and {{runSpringBoot}}: when the run ends, they keep the log of
the app as its previous run, and Spring Boot logs to {{<name>.log}}. The runner
module needs to carry that over.
_Claude Code on behalf of davsclaus_
> 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)
