Claus Ibsen created CAMEL-24659:
-----------------------------------
Summary: camel-jbang: add jbang as the default run runtime, and
make --runtime=main export and run via Maven like Spring Boot and Quarkus
Key: CAMEL-24659
URL: https://issues.apache.org/jira/browse/CAMEL-24659
Project: Camel
Issue Type: Improvement
Components: camel-jbang
Reporter: Claus Ibsen
Fix For: 4.23.0
h3. Background
{{camel run}} currently defaults to {{--runtime=main}}, which means the
integration runs in-process inside the jbang JVM. That JVM already carries
camel-jbang-core and all its dependencies (picocli, jline, Maven resolver,
catalog, kamelets catalog, dataweave, diagram, MCP server, log4j, ...) and
{{KameletMain}} then downloads the rest on the fly. This is great for fast
prototyping, but the classpath is far from what a production JVM looks like.
By contrast {{--runtime=spring-boot}} and {{--runtime=quarkus}} export to a
temporary project and spawn {{mvnw spring-boot:run}} / {{quarkus:dev}}, so the
integration runs in a clean JVM with exactly the dependencies an exported
project would have. A {{camel run pom.xml}} on an existing camel-main project
already spawns {{mvn camel:run}} (see {{Run.runExistingCamelMainProject}}), so
the export-then-run path for camel-main is a small step.
The name {{main}} therefore currently means two different things: in-process
when given source files, and Maven-driven when given a pom.xml.
h3. Proposal
* Add {{jbang}} to {{RuntimeType}} and make it the default for {{camel run}}.
This is the current in-process behaviour, unchanged. {{camel run}} is for
prototyping and this keeps startup instant.
* Change {{--runtime=main}} (aliases {{camel-main}}, {{camel}}) to export with
{{ExportCamelMain}} into the run directory and run it via {{mvnw camel:run}},
reusing the existing {{runExistingCamelMainProject}} code path. This makes all
three runtimes consistent: exported project, run by Maven, clean JVM.
* Pom auto-detection ({{RunHelper.detectRuntimeFromPom}}) should only apply
when the runtime is {{jbang}}, and should resolve a plain camel-main pom to
{{main}}.
* Options that only make sense in-process ({{--background}}, {{--source-dir}},
{{--code}}, {{--open-api}}, transform runs, MCP stdio mode, debug spawn) should
be rejected under {{main}} with the same "not supported" message already used
for Spring Boot / Quarkus.
* Dev mode under {{main}}: live reload of the original source files requires
pointing {{camel.main.routesReloadDirectory}} back at the source directory
since export copies the files; Java sources cannot hot reload (same limitation
as Spring Boot today, document it).
* Other commands taking {{--runtime}} ({{camel export}}, {{camel dependency}},
{{camel version}}, {{camel update}}, kubernetes plugin, SBOM) should treat
{{jbang}} as {{main}} since it is not a real runtime there.
* The {{camel.jbang.runtime}} profile property must accept the new value.
* Update the camel-jbang user manual and add an upgrade guide note that
explicit {{--runtime=main}} now exports and runs via Maven.
No deprecation period is needed: {{camel run}} is a prototyping tool and
{{camel export}} is the path to production with Spring Boot or Quarkus.
h3. Motivation from the TUI
The TUI ({{camel tui}}) needs a way to run an integration in a JVM that
resembles production, i.e. without the jbang CLI classpath mixed in. With this
change the TUI can run with {{--runtime=main}} (or Spring Boot / Quarkus) and
get a clean JVM with only the exported dependencies, so what is observed in the
Route, Diagram, Endpoints and Spans tabs matches what the user will ship. It
also avoids the class of bugs where an integration works under {{camel run}}
only because a transitive JAR happened to be on the jbang classpath, and then
breaks after {{camel export}}.
----
_Created by Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
