davsclaus opened a new pull request, #29812:
URL: https://github.com/apache/camel/pull/29812

   ## Summary
   
   Fixes the first item of 
[CAMEL-26912](https://issues.apache.org/jira/browse/CAMEL-26912): **exports 
that run at the same time in one directory corrupt each other and still report 
success.**
   
   Every `camel export` in a directory uses the same work directory, 
`.camel-jbang`: the silent run deletes it when it starts, writes the run 
settings there, and the exporter builds the project in `.camel-jbang/work`. 
Four exports started at the same time from one folder (an AI agent or a script 
exporting several routes):
   
   | | before | after |
   |---|---|---|
   | exit codes | 3 × exit 66 (`File not found: 
.camel-jbang/work/.../CamelApplication.java`), 1 × 0 | 4 × 0 |
   | `outa` | "Project export successful!" with the route of `b` | route `a`, 
artifactId `a`, one main class |
   | `outb`..`outd` | empty | their own route, artifactId and main class |
   
   ### Fix
   
   `ProjectExporter` lets one export at a time use a work directory 
(`WorkDirLock`):
   
   - a file lock for the exports of other processes, in the Camel directory of 
the user (`~/.camel/export-<uuid of the directory>.lock`), not in the work 
directory, which an export deletes
   - a lock per directory for the exports of the same process (API callers in 
threads), which a file lock does not tell apart
   - an export that has to wait says so: `Waiting for another export that uses 
.../.camel-jbang to finish`
   
   The four exports above take 13s together.
   
   ### Why not a work directory of its own per export
   
   I tried that first. It breaks a feature: `camel export` without files reuses 
the run data that the last `camel run` (or export) left in `.camel-jbang` 
("Reusing existing run data", `QuarkusPlatformLookupTest`). The Kubernetes 
export also reads those run settings, and the golden test records them. A lock 
keeps all of that as it is. Callers of the Java API that want exports in 
parallel keep giving each export a `workDir` of its own, as the `ExportRequest` 
javadoc says.
   
   Not covered: a `camel run` that starts in the same directory during an 
export still deletes `.camel-jbang`.
   
   ## Tests
   
   - `ProjectExporterTest.exportsInParallelWithTheDefaultWorkDir`: four exports 
in parallel in the default `.camel-jbang`, each project has its own route and 
artifactId. It fails without the lock (3 of 3 runs).
   - The CLI home of `ProjectExporterTest` is a temporary directory, so the 
lock files of the tests are not written in the home of the user.
   - camel-jbang-run (271 tests), and camel-jbang-core including 
`RunExportGoldenTest` and `QuarkusPlatformLookupTest`. The golden files are 
unchanged.
   - The four exports above with the unpacked launcher and the new 
camel-jbang-run jar.
   
   _Claude Code on behalf of Claus Ibsen (davsclaus)_
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   
   https://claude.ai/code/session_012nJsFsjqqFiwroeHRWaKbS
   


-- 
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]

Reply via email to