davsclaus opened a new pull request, #29778: URL: https://github.com/apache/camel/pull/29778
JIRA: [CAMEL-26901](https://issues.apache.org/jira/browse/CAMEL-26901) (finding 1, step 1). **Stacked on #29777** (camel run: leave out what is already on the classpath when resolving dependencies): this PR targets its branch. Review only the last commit. Merge #29777 first, then this PR is retargeted to `main`. ### One version of each library `camel run` downloads the JARs of each component when it is first used, and every component was resolved on its own. `alreadyOnClasspath` matches the exact version, so a library already loaded was added again when a later component depended on another version of it. Ten components (kafka, aws2-s3, sql, http, jms, mongodb, google-pubsub, azure-storage-blob, elasticsearch, infinispan) put 21 libraries on the classpath in more than one version: - Netty in 4.1.127, 4.1.138 and 4.1.139 - httpclient5 in 5.6.3, 5.6.4 and 5.6.5 - jackson-core in 2.18.2, 2.22.2 and 2.22.3 - OpenTelemetry in 1.62.0 and 1.67.0 A class was loaded from whichever JAR came first, so the classes of one library could come from different versions. Now the libraries already resolved for the class loader are passed as managed versions to the next resolutions, as the `dependencyManagement` of a Maven project would. A component loaded later gets the version already loaded, and the other version is not downloaded. With the same ten components: no library in more than one version, and 260 JARs added instead of 290. - `MavenDownloader.resolveArtifacts(..., Collection<MavenGav> managed)` is a new default method. `MavenDownloaderImpl` implements it with a `ManagedVersionDependencyManager` that wraps the session's dependency manager. - Versions are managed per groupId:artifactId, whatever the classifier. A first attempt with the managed dependencies of the `CollectRequest` (keyed with the classifier) still let `camel-infinispan` resolve `netty-transport-native-epoll:linux-aarch_64` in 4.1.139 next to `linux-x86_64` in 4.1.127. - A dependency asked for directly (depth 1) keeps its version, so `--dep=io.netty:netty-common:4.1.139.Final` is still that version. - Only `MavenDependencyDownloader` instances that add JARs to a class loader use it. A new downloader instance, such as the one for plugins, starts empty. The trade-off: the library version of the component loaded first wins, so a later component may run with an older version than it declares. That was already the case for every class both versions have. What changes is that the classes of a library are no longer mixed between versions. ### Tests - `MavenDownloaderImplTest`: a transitive dependency gets the managed version, and the other version is not downloaded; another classifier gets it too; a dependency asked for directly keeps its version. Run against a local file repository. - camel-tooling-maven and camel-kamelet-main: all tests pass. - By hand, with the launcher distribution patched with these JARs: the ten components above plus groovy, jsonpath and mustache. No library in more than one version, and the route runs. Upgrade guide: a note in 4.24. _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]
