gnodet opened a new pull request, #29805: URL: https://github.com/apache/camel/pull/29805
Fixes [CAMEL-26913](https://issues.apache.org/jira/browse/CAMEL-26913). > _This PR was opened by a coding agent (Hermes) on behalf of gnodet._ ## Summary Four bugs in the Camel CLI startup and configuration handling, all confirmed by reading the source and by experiment on main. ### 1. Malformed `~/.camel-cli.properties` breaks every CLI command **Root cause:** `CommandLineHelper.augmentWithUserConfiguration()` caught only `IOException`. A line like `path=C:\users\name` stores a bare backslash — `Properties.load()` treats `\u` as the start of a Unicode escape and throws `IllegalArgumentException` (not `IOException`), which propagated uncaught through every CLI command including `camel config` (which the user would need to fix it). **Fix:** Catch `Exception` and emit a diagnostic warning instead of crashing, so the command runs without user-configured defaults. The warning tells the user which file is broken and how to fix it. ### 2. `~/.camel-jbang-plugins.json` can be corrupted by concurrent writes **Root cause:** `PluginHelper.savePluginConfig()` and `createPluginConfig()` used `Files.writeString` with `TRUNCATE_EXISTING` — truncate then write in two steps. Two concurrent `camel` invocations can observe the file in a truncated/empty state, producing an NPE (`plugins == null`) or silently losing all entries on the next `camel plugin add`. **Fix:** Atomic write helper: write to a sibling `.tmp` file first, then `Files.move` with `ATOMIC_MOVE` (with a non-atomic `REPLACE_EXISTING` fallback for filesystems that don't support it). The target file is never partially written. ### 3. CDS archives shared between installs of the same version **Root cause:** `camel.sh` stored the CDS archive at `$XDG_CACHE_HOME/camel-cli/cds/<version>/<cmd>.jsa` with no install-directory component. Two installs of the same version (SDKMAN + Homebrew, zip + nightly, or a moved install) shared the archive. The archive bakes in the full path to the launcher JAR, so the wrong install's JAR was used for background processes (`camel run --background`), and `InstallDetector` reported the wrong install method (affecting `camel self-update` and the update notice). **Fix:** Compute a `cksum` hash of `$BASEDIR` and add it as an extra path segment: `…/<version>/<hash>/<cmd>.jsa`. Each install directory gets its own namespace of archives. ### 4. `camel --version` / `camel -V` triggers full plugin resolution **Root cause:** `PluginHelper.shouldDiscoverPlugins()` returned `true` for any arg starting with `-`, including `--version` and `-V`. Full plugin resolution contacts Maven Central for unresolvable plugins, making `camel -V` exit with code 1 when a plugin can't be resolved, and roughly 3× slower than `camel version`. **Fix:** Short-circuit `shouldDiscoverPlugins()` for `--version` and `-V` specifically. All other global flags (e.g. `--help`) still load plugins for the full listing. ## Tests - `UserConfigDefaultsTest.malformedUserConfigDoesNotCrashCli` — verifies fix 1 - `PluginHelperTest.savePluginConfigWritesAtomically` — verifies fix 2 (no stray `.tmp` files, expected content written) - `PluginHelperTest.savePluginConfigPreservesExistingFileOnWrite` — round-trip test for fix 2 - `PluginFilteringTest.versionFlagDoesNotDiscoverPlugins` — verifies fix 4 - `PluginFilteringTest.helpFlagStillDiscoverPlugins` — verifies `--help` is not affected - `PluginFilteringTest.noArgDiscoverPlugins` — verifies baseline still loads plugins All 3 affected test classes pass (59 + 10 tests total). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
