Skip to content

CAMEL-23654: camel-jbang - group commands in --help output by categor…#24276

Merged
davsclaus merged 2 commits into
apache:mainfrom
sk-reddy17:CAMEL-23654-jbang-group-help-by-category
Jun 28, 2026
Merged

CAMEL-23654: camel-jbang - group commands in --help output by categor…#24276
davsclaus merged 2 commits into
apache:mainfrom
sk-reddy17:CAMEL-23654-jbang-group-help-by-category

Conversation

@sk-reddy17

Copy link
Copy Markdown
Contributor

The camel --help output lists 40+ commands in one flat alphabetical list,
which is hard to scan. This groups them into categories (Running, Monitoring,
Actions, Development, Configuration, Catalog, AI) so it's easier to find what
you need.

Done with a small picocli IHelpSectionRenderer wired into CamelJBangMain.
Anything not mapped to a group falls into "Other", so no command gets dropped.

Fixes https://issues.apache.org/jira/browse/CAMEL-23654

Example

Commands:

Running:
  run          Run as local Camel integration
  dev          Run in dev mode with live reload
  stop         Shuts down running Camel integrations

Monitoring:
  get          Get status of Camel integrations
  top          Top status of Camel integrations

Configuration:
  config       Get and set user configuration values

Catalog:
  catalog      List artifacts from Camel Catalog

AI:
  ask          Ask a question about a running Camel application using AI
...

Test plan

  • Test checks all the category headers show up in --help
  • Test checks the key commands (run, get, config, catalog) are still listed
  • Ran camel --help by hand to confirm it looks right

@github-actions

Copy link
Copy Markdown
Contributor

🌟 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.

@github-actions github-actions Bot added the dsl label Jun 27, 2026
@github-actions

github-actions Bot commented Jun 27, 2026

Copy link
Copy Markdown
Contributor

🧪 CI tested the following changed modules:

  • dsl/camel-jbang/camel-jbang-core

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

  • dsl/camel-jbang/camel-jbang-core: 1 test(s) disabled on GitHub Actions

💡 Manual integration tests recommended:

You modified dsl/camel-jbang/camel-jbang-core. The related integration tests in dsl/camel-jbang/camel-jbang-it are excluded from CI. Consider running them manually:

mvn verify -f dsl/camel-jbang/camel-jbang-it -Djbang-it-test
All tested modules (6 modules)
  • Camel :: JBang :: Core
  • Camel :: JBang :: MCP
  • Camel :: JBang :: Plugin :: Route Parser
  • Camel :: JBang :: Plugin :: TUI
  • Camel :: JBang :: Plugin :: Validate
  • Camel :: Launcher :: Container

⚙️ View full build and test results

@davsclaus davsclaus left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this, @sk-reddy17 — grouping the help output is a welcome UX improvement. The categorizations look well thought out and all 37 built-in commands are covered.

A couple of minor suggestions for robustness (not blockers):

  1. Hidden-command filtering: The renderer iterates over all subcommands() without checking usageMessage().hidden(). The default picocli renderer filters hidden commands out. While there are no hidden top-level commands today, if a plugin registers one in the future it would unexpectedly appear in help. A one-line guard in both loops would future-proof this:

    if (sub.getCommandSpec().usageMessage().hidden()) continue;
  2. Maintenance guardrail: The static GROUPS map needs manual updating when new commands are added. The "Other" fallback handles this gracefully at runtime, but a test asserting that no built-in commands fall into "Other" would catch drift early — so developers adding a new command get a test failure reminding them to update the map.

  3. Test coverage: The tests check group headers and a few key commands, but don't verify that all registered commands appear in the output. A count-based assertion would be a stronger safety net.

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

@davsclaus davsclaus merged commit c72d149 into apache:main Jun 28, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants