[
https://issues.apache.org/jira/browse/CAMEL-24724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18115634#comment-18115634
]
Gaelle Fournier commented on CAMEL-24724:
-----------------------------------------
One note regarding the recently merged
[CAMEL-24681|https://github.com/apache/camel/pull/26293] : it added
`camel.extra.repos` and `camel.jbang.repos` system property lookups in
`ExportBaseCommand.getMavenRepositories()`, and consolidated repo-parsing into
`buildRepositoryList()`. This moves cleanly into `camel-jbang-export`. However,
when the export logic becomes a library API (ProjectExporter in stage 2), those
`System.getProperty()` calls should probably become explicit configuration on
the exporter API rather than hidden system property lookups: library consumers
won't expect side-channel configuration via system properties.
I was planning to create a jira issue on this follow-up but I guess its place
would be in this work now.
> 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)
