CAMEL-23680: Add group as scope to variables

[davsclaus]

Summary

• Adds a new built-in group variable scope alongside the existing exchange, route, and global scopes
• Group variables use the syntax group:groupId:variableName (e.g., group:teamA:threshold)
• Groups are user-managed by convention — the group name is picked in the variable key, no configuration needed
• Supports initial variable configuration via application.properties: camel.variable.group.teamA.xxx = value

Changes

• VariableRepositoryFactory — added GROUP_VARIABLE_REPOSITORY_ID constant
• GroupVariableRepository (new) — in-memory group-scoped variable repository modeled on RouteVariableRepository, with getGroupIds() API and wildcard removal (group:teamA:*)
• DefaultVariableRepositoryFactory — registers group repo as a built-in alongside global and route
• MainSupportModelConfigurer — supports camel.variable.group. prefix in properties initialization
• variables.adoc — documented group scope in repository list, Java API examples, and properties configuration

CLI (camel get variable), developer console, JMX, and TUI pick up the group repository automatically via BrowsableVariableRepository — no changes needed in those modules.

Test plan

• GroupVariableRepositoryTest — 14 unit tests covering set/get, isolation, wildcards, getGroupIds(), error cases
• SetGroupVariableTest — 4 integration tests covering route DSL, group isolation, Simple language access, cross-route sharing

Claude Code on behalf of Claus Ibsen

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

[github-actions]

🧪 CI tested the following changed modules:

• core/camel-api
• core/camel-base-engine
• core/camel-core
• core/camel-main
• core/camel-support
• docs

ℹ️ 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.

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

• core/camel-core: 2 test(s) disabled on GitHub Actions

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

• Camel :: API
• Camel :: Base Engine
• Camel :: Core
• Camel :: Docs
• Camel :: Main
• Camel :: Support

---

⚙️ View full build and test results

[davsclaus]

Review: CAMEL-23680 — Add group as scope to variables

Clean, well-structured addition that follows the established RouteVariableRepository pattern closely. CI is green, test coverage is solid (14 unit + 4 integration tests).

Findings

1. Missing upgrade guide entry (Medium)
Per project conventions, user-visible changes should be documented in the upgrade guide. This PR adds a new built-in variable scope (group) and reserves the id "group" for Camel's internal use. Anyone who happened to have a custom VariableRepository with id "group" would be affected since it now gets intercepted by the factory. An entry in camel-4x-upgrade-guide-4_21.adoc should mention:

• New group variable scope is available
• The id group is now reserved (along with the already-reserved global, route, exchange, header)

2. Stale empty group maps after individual variable removal (Low — cosmetic, consistent with existing code)
In GroupVariableRepository.setVariable(), setting a value to null removes the key from the inner map but does not remove the outer group entry when the inner map becomes empty. This means getGroupIds() could return group names that have no variables. This is the exact same behavior as RouteVariableRepository, so it's consistent and not a regression — just noting it since getGroupIds() is a new API and users may expect it to only return groups that actually have variables.

3. No automatic lifecycle cleanup for groups (Question — likely intentional)
RouteVariableRepository has a LifecycleStrategySupport that automatically removes route variables when routes are removed. Groups have no equivalent cleanup. This seems intentional since groups are user-managed by convention, but wanted to confirm.

What looks good

• Implementation follows the exact same pattern as RouteVariableRepository — thread-safe, proper StreamCache handling
• @since 4.21 Javadoc tags on new public API
• Documentation is clear with Java API and application.properties examples
• Group repo auto-registers via BrowsableVariableRepository, so CLI/console/JMX picks it up for free

This review does not replace specialized 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]

Minor observation: when value is null, the key is removed from the inner map, but if the inner map becomes empty, the group entry remains in the groups outer map. This means getGroupIds() could return group names with zero variables.

This is the same behavior as RouteVariableRepository, so it's consistent — just noting it since getGroupIds() is a new user-facing API.