CAMEL-23683 add camel-shell component

[johnpoth]

Description

https://issues.apache.org/jira/browse/CAMEL-23683

I think it would be cool to have a small camel-shell component that communicates with other camel endpoints so far example:

from("shell:prompt")
    .to("huggingface:chat?modelId=Qwen/Qwen2.5-3B-Instruct");

This would start the Java Camel process in "shell" mode and route user typed messages to the Qwen model. The idea would be valid for any camel endpoints.

Also maybe add a camel-command component in the future to have some runtime commands (fetch metrics etc..)

Here are some GIFS of what it looks like, let me know what you think !

Target

• I checked that the commit is targeting the correct branch (Camel 4 uses the main branch)

Tracking

• If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

• I checked that each commit in the pull request has a meaningful subject line and body.

• I have run mvn clean install -DskipTests locally from root folder and I have committed all auto-generated changes.

[davsclaus]

Cool idea — an interactive terminal component that routes user input to any Camel endpoint. The code is clean and well-structured. A few items to address before merge.

Version numbers: The component uses 4.19.0-SNAPSHOT / firstVersion = "4.19.0" / :since: 4.19, but the current SNAPSHOT is 4.21.0-SNAPSHOT. All should be updated to 4.21.

Tests: Per project conventions, every PR must include tests for new functionality. While the interactive terminal nature makes full integration testing harder, at minimum the component lifecycle, endpoint configuration, and pure functions like resolveColor() can be unit-tested.

Observations (non-blocking):

• terminal.puts(InfoCmp.Capability.clear_screen) in doStart() clears the user's terminal on startup — could be surprising. Consider making this opt-in.
• getCamelContext().stop() in the consumer's finally block means EOF/exit shuts down the entire Camel context. Worth documenting explicitly — users might not expect Ctrl+D to stop their application.
• Category.API in @UriEndpoint doesn't seem fitting for a terminal component.
• The "shell" name might conflict with the OS shell concept or the existing camel shell JBang command. Users might expect shell: to execute OS commands. Consider console: or terminal: — though this is a design choice.

This review does not replace specialized AI review tools (CodeRabbit, Sourcery) or static analysis (SonarCloud).

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

[davsclaus]

firstVersion should be 4.21.0 (current SNAPSHOT is 4.21.0-SNAPSHOT, not 4.19.0-SNAPSHOT).

Suggested change

	@UriEndpoint(firstVersion = "4.19.0", category = { Category.API }, scheme = "shell", title = "Shell",
	@UriEndpoint(firstVersion = "4.21.0", category = { Category.API }, scheme = "shell", title = "Shell",

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[davsclaus]

Thanks for fixing the version numbers — all 4.21 now. Two remaining items:

CI failure: The full reactor build generates additional files that aren't committed (EndpointBuilderFactory, camel-component-known-dependencies.properties, etc.). Please run mvn clean install -DskipTests from the repository root and commit all auto-generated changes.

Tests: Still missing. Per project conventions, new functionality should include tests. While the interactive terminal makes integration testing harder, unit tests for component lifecycle, endpoint configuration, and resolveColor() are feasible.

This review does not replace specialized AI review tools (CodeRabbit, Sourcery) or static analysis (SonarCloud).

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

[davsclaus]

Thanks for adding the tests and fixing the version numbers — good progress! A couple of items still need attention.

1. Missing configureConsumer(consumer) in ShellEndpoint.createConsumer() — Without this call, bridgeErrorHandler, exceptionHandler, and exchangePattern are advertised as endpoint options but have no effect. This is the standard Camel pattern used by every consumer-supporting component (see e.g. camel-iggy, camel-telegram).

2. CI failure — "Fail if there are uncommitted changes" is still failing. Please run mvn clean install -DskipTests from the repository root and commit all auto-generated file changes.

3. remote: true should be false — This is a local terminal component (reads from stdin), not a remote one. Comparable local components (camel-seda, camel-exec, camel-direct) all use "remote": false.

This review does not replace specialized AI review tools (CodeRabbit, Sourcery) or static analysis (SonarCloud).

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

[gnodet]

Nice new camel-shell component using JLine. The implementation is clean and follows Camel component conventions well:

• ShellComponent: Manages JLine terminal lifecycle, banner display, and LineReader creation
• ShellConsumer: Read loop that sends each line as an exchange body and prints the response
• ShellEndpoint: Consumer-only endpoint with prompt and color parameters
• Good test coverage: component registration, endpoint creation, color resolution, producer rejection

The component is consumer-only (as expected for an interactive shell), properly handles EOF and exit commands, and shuts down the CamelContext when the shell exits. Documentation includes practical examples (LLM chat, REST API, JMS fire-and-forget).

Fully automatic review from Claude Code

[davsclaus]

@johnpoth can you fix the findings and update this PR

[github-actions]

🧪 CI tested the following changed modules:

• bom/camel-bom
• catalog/camel-allcomponents
• catalog/camel-catalog
• components
• components/camel-shell
• core/camel-main
• docs
• dsl/camel-componentdsl
• dsl/camel-endpointdsl
• dsl/camel-kamelet-main
• parent

ℹ️ Dependent modules were not tested because the total number of affected modules exceeded the threshold (50). Use the test-dependents label to force testing all dependents.

✅ POM dependency changes: targeted tests included

Changed managed dependencies: org.apache.camel:camel-shell

Modules affected by dependency changes (10)

• :apache-camel
• :camel-allcomponents
• :camel-bom
• :camel-catalog
• :camel-componentdsl
• :camel-endpointdsl
• :camel-kamelet-main
• :camel-main
• :camel-shell
• :docs

🔬 Detected via Maveniverse Scalpel effective POM comparison

⚠️ Some tests are disabled on GitHub Actions (@DisabledIfSystemProperty(named = "ci.env.name")) and require manual verification:

• components: 103 test(s) disabled on GitHub Actions

Build reactor — dependencies compiled but only changed modules were tested (12 modules)

• Camel :: All Components Sync point
• Camel :: Assembly
• Camel :: BOM
• Camel :: Catalog :: Camel Catalog
• Camel :: Component DSL
• Camel :: Components
• Camel :: Docs
• Camel :: Endpoint DSL
• Camel :: Kamelet Main
• Camel :: Main
• Camel :: Parent
• Camel :: Shell

---

⚙️ View full build and test results

[johnpoth]

Thanks @davsclaus and @gnodet for reviewing! Merged... maybe this should look more like the TUI we have in the CLI in the future... we'll see, thanks !