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

   JIRA: [CAMEL-26901](https://issues.apache.org/jira/browse/CAMEL-26901) 
(finding 4, and the two classpath bugs from the JIRA comment). Independent of 
#29774 (camel run: fail fast on declared dependencies, base version for remote 
SNAPSHOTs); the two merge without conflicts.
   
   ### Leave out what is already on the classpath while resolving
   
   `MavenDependencyDownloader` resolved the whole dependency tree of a 
component, downloading every JAR and POM, and only then filtered out what was 
already on the classpath. Now the JARs on the classpath the JVM was started 
with are left out of the resolution, together with their own dependencies, 
through a dependency selector. They are not downloaded, and neither are their 
POMs.
   
   - `MavenDownloader.resolveArtifacts(..., Predicate<MavenGav> available)` is 
a new default method; `MavenDownloaderImpl` implements it with an 
`AvailableDependencySelector`.
   - A JAR matches by file name: `artifactId-version.jar`, or 
`artifactId-version-classifier.jar` when there is a classifier. So a native 
classifier JAR is not mistaken for the plain one.
   - Only the downloads that add JARs to a class loader use it. 
`downloadArtifacts` (catalogs, version lookups) is unchanged.
   
   ### The launcher's classpath
   
   The launcher distribution starts with `java -jar camel-launcher.jar` and 
lists its JARs in the manifest `Class-Path`. So `java.class.path` held only the 
launcher JAR, and the "already on the classpath" checks never matched. A small 
route added 57 JARs to the download class loader, against 14 when started 
through jbang; camel-api, camel-support, ... were on the classpath twice. 
`BootClasspath` now reads the manifest `Class-Path` when the classpath is a 
single JAR (the `java -jar` case).
   
   ### Artifact ids with dots
   
   `alreadyOnClasspath` built the path to look for with `(groupId + "/" + 
artifactId).replace('.', '/')`, which also replaced the dots inside the 
artifact id. So `jakarta.activation-api` and `jakarta.xml.bind-api` never 
matched, and were added again for every dependency that needed them (8 times in 
one run).
   
   ### Hawtio
   
   `camel hawtio` downloads into a class loader without a parent. What is on 
the classpath is now added to it as well, since that class loader does not see 
the classpath. Before, it got all JARs with the launcher (because the check 
never matched), and was missing the ones on the jbang classpath.
   
   ### Measured
   
   Small YAML route (groovy, jsonpath, mustache), launcher distribution, 
4.24.0-SNAPSHOT:
   
   | | before | after |
   |---|---|---|
   | Cold run (empty local repository), wall time | 13.7s / 16.2s | 7.0s / 6.5s 
|
   | JARs downloaded | 43 (20.9 MB) | 10 (8.8 MB) |
   | POMs downloaded | 105 | 37 |
   | JARs added to the class loader, cold | 117 | 10 |
   | JARs added to the class loader, warm | 57 | 10 |
   
   All 23 JARs that are no longer added are in the launcher's `lib`. 21 are 
core Camel JARs (with a timestamped SNAPSHOT version; #29774 handles that 
separately). The other two are `asm` 9.7.1 (`lib` has 9.11.1) and 
`snakeyaml-engine` 3.2 (`lib` has 3.0.1). Classes load parent-first, so the 
`lib` versions already won before; the two versions are no longer mixed.
   
   Also checked by hand with the patched launcher:
   - A run with an explicit `-cp` of all JARs, as jbang starts it: 10 added, 
route runs.
   - `camel hawtio`: the console answers with 200.
   
   ### Tests
   
   - `MavenDownloaderImplTest`: an available artifact and its dependency are 
left out (not even their POMs are downloaded), against a local file repository.
   - `BootClasspathTest`: file name and classifier matching, and the manifest 
`Class-Path` of `java -jar` (including a directory with a space).
   - camel-tooling-maven and camel-kamelet-main: all tests pass.
   
   _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