[
https://issues.apache.org/jira/browse/CAMEL-24724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ricardo Martinez updated CAMEL-24724:
-------------------------------------
Description:
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-runner; Run.run<Runtime>() delegate to
ProjectRunner|https://issues.apache.org/jira/browse/CAMEL-24726|
|2|camel-jbang-core|Extract camel-jbang-export; picocli removed from export/run
path| |
|3|camel-jbang-plugin-tui|TUI calls ProjectRunner Java API instead of spawning
camel binary| |
|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.
was:
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||
|1|camel-jbang-core|Extract camel-jbang-runner; Run.run<Runtime>() delegate to
ProjectRunner|
|2|camel-jbang-core|Extract camel-jbang-export; picocli removed from export/run
path|
|3|camel-jbang-plugin-tui|TUI calls ProjectRunner Java API instead of spawning
camel binary|
|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.
> 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-runner; Run.run<Runtime>() delegate
> to ProjectRunner|https://issues.apache.org/jira/browse/CAMEL-24726|
> |2|camel-jbang-core|Extract camel-jbang-export; picocli removed from
> export/run path| |
> |3|camel-jbang-plugin-tui|TUI calls ProjectRunner Java API instead of
> spawning camel binary| |
> |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)
