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

   JIRA: [CAMEL-26901](https://issues.apache.org/jira/browse/CAMEL-26901) (the 
first step of its suggested order: findings 2 and 3)
   
   ### camel run stops when a dependency it was given cannot be downloaded
   
   Before, `camel run --dep=com.example.nope:doesnotexist:1.0` logged an ERROR 
with about 40 lines of stack trace, started the routes without the dependency, 
and exited with 0. The `DownloadThreadPool` caught the failure and returned.
   
   Now a dependency the user declares is required when running: `--dep`, 
`camel.jbang.dependencies`, a `//DEPS` line, or the dependencies of a Kamelet. 
If it cannot be downloaded, the run stops with exit code 1 and one line:
   
   ```
   ERROR: Cannot download dependency: com.example.nope:doesnotexist:1.0 due to: 
The following artifacts could not be resolved: 
com.example.nope:doesnotexist:jar:1.0 (absent): Could not find artifact 
com.example.nope:doesnotexist:jar:1.0 in central 
(https://repo1.maven.org/maven2)
   ```
   
   - `DependencyDownloader.downloadRequiredDependency` throws a 
`DownloadException` with the message of Maven Resolver, instead of logging it. 
`CommandLineDependencyDownloader` and `DependencyDownloaderStrategy` (which 
handles `//DEPS` and Kamelet dependencies) use it when KameletMain is not 
exporting or transforming.
   - `camel export` and `camel transform` stay lenient as before: export still 
writes the dependency to the exported pom.
   - `--dev`: a reload with a `//DEPS` line that cannot be downloaded fails 
with that one-line reason, and the routes keep running as they were.
   - Automatically detected dependencies (components, languages, ...) are 
unchanged in this PR.
   - `CliExecutionExceptionHandler` ends a `DownloadException` with exit code 1 
and its message, instead of 70 (internal error) with the stack trace 
(`--verbose` still prints it). A missing or unreachable artifact is not a bug 
in Camel.
   
   ### A remote SNAPSHOT is not added to the classpath again
   
   `MavenDownloaderImpl` gave a resolved artifact its version, which for a 
SNAPSHOT from a remote repository is the timestamped one 
(`4.24.0-20261112.143700-31`). That never matched 
`camel-api-4.24.0-SNAPSHOT.jar` on the classpath. So a cold run of the nightly 
CLI added camel-api, camel-support, camel-util, camel-core-model, ... to the 
download class loader again, some of them 3 times. The artifact now has its 
base version (`4.24.0-SNAPSHOT`); the file is unchanged.
   
   ### Tests
   
   - `MavenDownloaderImplTest`, `DownloadThreadPoolTest`, 
`CommandLineDependencyDownloaderTest`, `DependencyDownloaderStrategyTest` and 
`ExitCodeContractTest`.
   - camel-tooling-maven and camel-kamelet-main: all tests pass. 
camel-jbang-core: `ExitCodeContractTest`, `RunTest` and `TransformRouteTest` 
pass.
   - By hand, with the launcher distribution patched with these jars:
     - `--dep` and `//DEPS` with a missing artifact: exit 1, one `ERROR:` line.
     - A run with `--dep=camel:kafka`, and a route using a built-in Kamelet 
(`kamelet:timer-source`): unchanged.
     - A cold run (empty local repository) of the SNAPSHOT: camel jars added 
with their base version.
     - `camel export --dep=<missing>`: exit 0, dependency in the pom, as before.
     - `--dev` reload with a bad `//DEPS` line: reload fails, routes keep 
running.
   
   ### Found while testing (not in this PR, added to CAMEL-26901)
   
   - **Launcher distribution:** the distribution starts with `java -jar 
camel-launcher.jar` and lists its jars in the manifest `Class-Path`. So 
`java.class.path` holds only the launcher jar, and the "already on the 
classpath" check of `MavenDependencyDownloader` never matches. A warm run adds 
57 jars to the download class loader, against 14 when started through jbang; 
core jars are on the classpath twice.
   - **Artifact ids with dots:** `alreadyOnClasspath` builds the path with 
`(groupId + "/" + artifactId).replace('.', '/')`, which also replaces the dots 
inside the artifactId. So `jakarta.activation-api` and `jakarta.xml.bind-api` 
never match, and were added 8 times in one run.
   
   _Claude Code on behalf of Claus Ibsen (davsclaus)_
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


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