Claus Ibsen created CAMEL-26912:
-----------------------------------
Summary: camel-jbang - camel export: concurrent exports corrupt
each other, the export directory is wiped, application.properties is mangled,
and the Kamelets catalog is downloaded every time
Key: CAMEL-26912
URL: https://issues.apache.org/jira/browse/CAMEL-26912
Project: Camel
Issue Type: Bug
Components: camel-jbang
Reporter: Claus Ibsen
Fix For: 4.24.0
Found by an analysis of the Camel CLI on the night of 2026-11-12, with the
unpacked 4.24.0-SNAPSHOT camel-launcher on macOS. *(exp)* means reproduced by
experiment, *(read)* means traced in the code. Paths are relative to
{{dsl/camel-jbang/}}, and line numbers are from main at that time. Dependency
resolution of camel run is covered separately by CAMEL-26901.
h3. 1. Concurrent exports or runs in one folder corrupt each other and report
success (exp, high)
{{ExportRequest}} uses the shared {{.camel-jbang/work}} directory, and
{{RunPipeline.prepareWorkDir}} (RunPipeline.java around line 272) deletes it.
Four parallel exports of different routes from one folder: 2 failed with exit
66, and 2 printed "successful", but one exported project held another export's
route, the wrong artifactId and two main classes.
This also hits an AI agent or a script that exports while a {{camel run}} is
going on in the same folder. Suggested fix: a work directory per export/run (or
a lock).
h3. 2. Exporting into a directory other than the current one deletes its
contents with no prompt (exp)
The export directory is cleaned before the copy
({{ExportHelper.cleanExportDir}}, called from
CamelMainExporter/SpringBootExporter/QuarkusExporter around lines 202-216), so
files the user put there are gone ({{TODO.txt}} and {{docs/notes.txt}} in the
test), and a failed export leaves nothing.
This is deliberate since CAMEL-21104, but only {{--clean-dir}} asks for
confirmation. Suggestion: refuse (or ask) when the directory holds files that
are not from a previous export, or only delete after the export succeeded.
h3. 3. application.properties is corrupted on export (exp)
{{Properties}} unescapes on load, then {{Exporter.applicationPropertyLine}}
(Exporter.java around line 988) writes {{key=value}} raw:
{noformat}
path=C:\\temp\\new -> becomes C:<TAB>emp<NEWLINE>ew
regex=^\\d+$ -> becomes ^d+$
my.key\ with\ space=1 -> becomes the key "my.key" with value "with
space=1"
{noformat}
h3. 4. UTF-8 application.properties is double-encoded (exp)
{{RuntimeUtil.loadProperties}} (camel-jbang-core {{common/RuntimeUtil.java}}
around line 280) loads with {{Properties.load(InputStream)}}, which is
ISO-8859-1, and the result is written as UTF-8: {{æøå}} becomes {{æøå}}.
h3. 5. Two files with the same name in different directories collapse into one
(exp)
{{Exporter.java}} around line 703 copies with
{{targetDir.resolve(source.getFileName())}} (and Quarkus uses {{stripPath}}):
exporting {{x/route.camel.yaml}} and {{y/route.camel.yaml}} gives one file, and
one route is silently lost. It should fail, or keep the relative path.
h3. 6. Local lib JARs break the export (exp)
The {{systemPath}} in the pom is built from the artifactId and version
({{main-pom.ftl}} line 111), but the JAR is copied with its own file name, so
{{mvn}} fails on the exported project. Exporting a directory that contains a
JAR fails with exit 66, and the JAR is also copied into {{src/main/resources}}.
h3. 7. Every export downloads the Kamelets catalog, even with no Kamelets (exp)
{{Exporter.java}} around line 290 always calls
{{KameletCatalogHelper.loadKamelets}}, which uses its own downloader that
ignores {{--maven-settings}} and mirrors. With a fresh home an export of a
plain route takes 15.2s vs 1.5s warm: 38 MB of the 53 MB downloaded is the
camel-kamelets-catalog tree (fabric8, vert.x, ...). Offline, the export of a
route with no Kamelets fails (read). Only load it when a source refers to a
Kamelet.
h3. 8. Run directories are left behind (read)
The {{.camel-jbang-run/<millis>}} directories of the Spring Boot, Quarkus and
main runners are only removed by a shutdown hook, so a crash leaves the project
plus its {{target/}} forever. {{Debug.java}} around line 440 deletes the whole
{{.camel-jbang-run}}, including the directories of other live runs.
h3. 9. Windows (read)
* {{Exporter.getScheme}} treats {{C:}} as a scheme, so absolute TLS, classpath
and JKube files are dropped.
* {{MavenCommand}} falls back to {{mvn}} and not {{mvn.cmd}}.
h3. Came out clean
Warm export speed is 1.5s (main) to 1.9s (Spring Boot, Quarkus), one silent run
per export; the Quarkus registry call has a 20s timeout and a daily cache;
{{mvn}} runs with {{inheritIO}} and its exit code is checked.
h3. Suggested order
# 1 and 2 (data loss)
# 3, 4, 5 (silent corruption of the exported project)
# 7 (speed and offline)
# the rest
_Claude Code on behalf of Claus Ibsen (davsclaus)_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
