Fix CamelConfigITCase.testCamelListConfig

[apupier]

The order of config in the output is not important, check only if they are all there

it avoids this error:

[command  camel config list should output gav =
com.foo:acme:1.0-SNAPSHOT
runtime = quarkus
directory = /deployments/data/84965e9286b07]
Expecting actual:
  "----- Global -----
gav = com.foo:acme:1.0-SNAPSHOT
directory = /deployments/data/84965e9286b07
runtime = quarkus
"
to contain:
  "gav = com.foo:acme:1.0-SNAPSHOT
runtime = quarkus
directory = /deployments/data/84965e9286b07"

Description

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.

AI-assisted contributions

• If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., Co-authored-by trailers) and the PR description identifies the AI tool used.

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

• dsl/camel-jbang/camel-jbang-it

---

🔬 Scalpel shadow comparison — Scalpel: 1 tested, 0 compile-only — current: 0 all tested

Maveniverse Scalpel detected 1 affected modules (current approach: 0).

⚠️ Modules only in Scalpel (1)

• camel-jbang-it

Skip-tests mode would test 1 modules (1 direct + 0 downstream), skip tests for 0 (generated code, meta-modules)

Modules Scalpel would test (1)

• camel-jbang-it

ℹ️ Shadow mode — Scalpel observes but does not affect test execution. Learn more

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

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

---

⚙️ View full build and test results

[gnodet]

The intent of this change is good — checking each config line independently to avoid order-sensitivity. However, the implementation has a compilation issue.

checkCommandOutputs(String command, String contains) in JBangTestSupport takes a single String, but this PR passes a String[]. This would fail to compile.

CI didn't catch it because camel-jbang-it has <maven.test.skip>true</maven.test.skip> by default, which skips test compilation entirely.

Two possible fixes:

1. Add an overload to JBangTestSupport — something like:

   protected void checkCommandOutputs(String command, String... contains) {
       String output = execute(command);
       for (String c : contains) {
           Assertions.assertThat(output)
                   .as("command " + getMainCommand() + " " + command + " should output " + c)
                   .contains(c);
       }
   }

   This leverages AssertJ per-line and keeps the order-independent semantics.

2. Use individual calls (simpler, no shared code change):

   String output = execute("config list");
   assertThat(output).contains("gav = com.foo:acme:1.0-SNAPSHOT");
   assertThat(output).contains("runtime = quarkus");
   assertThat(output).contains("directory = " + mountPoint());

Option 1 is cleaner since it creates a reusable pattern for other tests that might have the same order-sensitivity problem.

Review generated with AI assistance — please verify before applying.
On behalf of @gnodet

[gnodet]

⚠️ Compilation error: checkCommandOutputs(String, String) does not have an overload accepting String[]. This code won't compile.

Since the existing checkCommandOutputs only takes a single String, you'll need to either add a varargs overload in JBangTestSupport or check each line individually.

Suggested varargs overload for JBangTestSupport:

protected void checkCommandOutputs(String command, String... contains) {
    String output = execute(command);
    for (String c : contains) {
        Assertions.assertThat(output)
                .as("command " + getMainCommand() + " " + command + " should output " + c)
                .contains(c);
    }
}

Note: changing the existing (String, String) signature to (String, String...) is source-compatible — all existing callers pass a single string which matches the varargs.

[gnodet]

Thanks for the update — the varargs overload is the right approach and addresses the compilation issue from the first revision.

Two remaining items:

1. testCamelUnsetConfig has the same order-sensitivity bug — it still uses the concatenated string pattern at line 50–53. Since it calls checkCommandOutputs("config list", ...) with the same multi-line expected output, it will be flaky for the same reason. Should be converted to use the new varargs overload too.

2. .as() message prints array reference — In the new varargs method, "... should output each of these lines " + contains will print [Ljava.lang.String;@<hash> since contains is a String[]. Use java.util.Arrays.toString(contains) for a readable message. Also minor: there's a double space in "command " (the existing single-arg version uses one space).

Item 1 is the important one — it defeats the purpose of the PR if the same test class still has the same flaky pattern elsewhere.

Review generated with AI assistance — please verify before applying.
On behalf of @gnodet

[gnodet]

Two nits:

1. + contains → + java.util.Arrays.toString(contains) (otherwise this prints [Ljava.lang.String;@hash)
2. Double space: "command " → "command "

Suggested change

	.as("command " + getMainCommand() + " " + command + " should output each of these lines " + contains)
	protected void checkCommandOutputs(String command, String... contains) {
	Assertions.assertThat(execute(command))
	.as("command " + getMainCommand() + " " + command + " should output each of these lines " + java.util.Arrays.toString(contains))
	.contains(contains);
	}