Croway opened a new pull request, #28239: URL: https://github.com/apache/camel/pull/28239
_Claude Code on behalf of Croway_ [CAMEL-25921](https://issues.apache.org/jira/browse/CAMEL-25921) ## Problem Maven 3.10 (Maven Resolver 2.0.23+) tracks where each artifact was downloaded from in `_remote.repositories` with a URL-qualified key (`file>central-<sha1(url)>=`) instead of the ID-only key (`file>central=`). The Maven Resolver 1.9 embedded in `camel-tooling-maven` only recognizes the ID-only keys, so with a local repository written by Maven 3.10: - every cached artifact is verified again against the remote repositories, and `--offline` resolution fails; - with `preferLocal` (Camel JBang plugins), the offline-first attempt could not build the plugin POM (its parent imports BOMs that look unavailable), Maven's default descriptor policy ignored that, and the plugin was resolved and cached with **no dependencies** → `NoClassDefFoundError`. The second symptom is not limited to Maven 3.10: the offline attempt shared the session's `RepositoryCache` with the online retry, so a POM that could not be read offline was reused, empty, online. With a local repository written by Maven 3.9, Camel JBang 4.22.1 silently dropped `snakeyaml` from the Forage plugin classpath. ## Changes - `TrackingKeyCompatLocalRepositoryManager` wraps the local repository manager (standalone mode only: in a Maven plugin the session is Maven's own). It also accepts a `<repoId>-<sha1>` entry for the same repository id, whatever the URL (Maven hashes the URL it knows the repository by, e.g. `repo.maven.apache.org`, while Camel uses `repo1.maven.org`). This is the trust level of the ID-only entries, and what Maven Resolver 2.0.23 itself does when it reads ID-only entries. Nothing changes in what Camel writes, which Maven 3.9 and 3.10 both read. - `preferLocal` now resolves once, with the session update policy set to `never` (like `mvn --no-snapshot-updates`), instead of resolving offline first and online on failure. What is cached is not checked again remotely and what is missing is still downloaded. There is no fallback any more, so neither the silently empty descriptors nor the cache sharing can happen. Since CAMEL-23335, plugins cache their resolved classpath, so this resolution only runs on a cache miss. Upgrading to Maven Resolver 2.x was not an option: `camel-report-maven-plugin` and `MavenVersionManager` use `camel-tooling-maven` in embedded mode, inside the user's Maven, which is still Maven 3.9 / Resolver 1.9 for many users. ## Testing - `MavenDownloaderTrackingKeyTest` (no network): legacy key accepted, URL-qualified key accepted, a key of another repository id with the same prefix (`myrepo-other-…`) rejected, plugin whose parent imports a BOM tracked by Maven 3.10, BOM missing from the local repository. Three of them fail on `main`. - `MavenDownloaderImplTest` with `-DenableMavenDownloaderTests=true`: all pass except `testDisableMavenCentral`, which fails the same way on `main` when commons-lang3 is already in `~/.m2`. - Real CLI (Camel JBang 4.22.1 classpath with the patched module, isolated `user.home`, local repository populated by Maven 3.10.0, `camel plugin add forage` then `camel forage --help`): | Local repository written by | before | after | |---|---|---| | Maven 3.10.0 | 2 classpath entries, `NoClassDefFoundError` | 47 entries, plugin loads | | Maven 3.9.12 | 46 entries (`snakeyaml` missing), plugin loads | 47 entries, plugin loads | - After Camel resolved into them, Maven 3.10.0 and 3.9.12 both still resolve the same artifacts offline from these repositories. A backport to `camel-4.22.x` follows as a separate PR. The fix applies cleanly there. -- 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]
