[jira] [Updated] (CAMEL-25921) camel-jbang - plugins resolve with no dependencies (or are re-downloaded) when the local Maven repository was written by Maven 3.10

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-25921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen updated CAMEL-25921:
--------------------------------
    Fix Version/s: 4.24.0
                   4.22.3

> camel-jbang - plugins resolve with no dependencies (or are re-downloaded) when the local Maven repository was written by Maven 3.10
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25921
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25921
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-jbang
>    Affects Versions: 4.18.4, 4.20.0, 4.22.1
>            Reporter: Federico Mariani
>            Assignee: Federico Mariani
>            Priority: Major
>             Fix For: 4.22.3, 4.24.0
>
>
> Since Maven 3.10.0 (Maven Resolver 2.0.23+), the local repository tracking files ({{_remote.repositories}}) record artifact provenance with a URL-qualified repository key, e.g.
> {noformat}
> langchain4j-bom-1.13.0.pom>central-8fac3ebd6edbaca3c794783fa38088af0aa128e7=
> {noformat}
> instead of the legacy ID-only key ({{langchain4j-bom-1.13.0.pom>central=}}). This is the new default of {{aether.system.trackingRepositoryKeyFunction}} ({{nid_hurl}}), introduced as hardening against local repository poisoning.
> {{camel-tooling-maven}} embeds Maven Resolver 1.9.27 (via MIMA), which only understands ID-only entries. With a local repository populated by Maven 3.10, every cached artifact is considered "not downloaded from this repository before", which leads to two problems in Camel JBang plugin resolution.
> h3. 1. Offline-first plugin resolution silently returns no dependencies (4.20+ / 4.22)
> {{PluginHelper.downloadPlugin}} sets {{preferLocal=true}}, so {{MavenDownloaderImpl.resolveArtifacts}} first resolves offline when the requested GAV exists in the local repository. When the plugin POM model cannot be built offline (e.g. its parent imports BOMs that are "invisible" because of the tracking keys above), Maven Resolver's default {{ArtifactDescriptorPolicy}} ignores the missing/invalid descriptor and returns the plugin with *no* transitive dependencies. No exception is thrown, so the online fallback never runs, and {{writeCache}} persists the incomplete classpath in {{~/.camel-jbang-plugins.json}}:
> {noformat}
> "classpath": [
>   ".../camel-jbang-parent-4.22.1.pom",
>   ".../camel-jbang-plugin-forage-1.6.2-SNAPSHOT.jar"
> ]
> {noformat}
> Loading the plugin then fails while picocli reflects the command classes:
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError: io/kaoto/forage/catalog/reader/ForageCatalogReader$FactoryMetadata
> 	at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
> 	...
> 	at picocli.CommandLine.<init>(CommandLine.java:199)
> 	at io.kaoto.forage.plugin.ForagePlugin.customize(ForagePlugin.java:33)
> 	at org.apache.camel.dsl.jbang.core.common.PluginHelper.addPlugins(PluginHelper.java:179)
> 	at org.apache.camel.dsl.jbang.core.commands.CamelJBangMain.execute(CamelJBangMain.java:245)
> {noformat}
> The same resolution with a local repository written by Maven 3.9 resolves 46 classpath entries and the plugin loads.
> h3. 2. Everything is re-downloaded (4.18.x)
> Without the offline-first path, the resolver logs "Artifact ... is present in the local repository, but cached from a remote repository ID that is unavailable in current build context" for every artifact and downloads it again, making plugin/dependency resolution much slower.
> h3. Reproducer
> Linux container ({{eclipse-temurin:21-jdk}}), Maven 3.10.0, Camel JBang 4.22.1, any third-party plugin whose POM parent imports BOMs (here: Kaoto Forage, {{io.kaoto.forage:camel-jbang-plugin-forage}}):
> {noformat}
> # 1. populate ~/.m2 with Maven 3.10.0 (e.g. build a project / dependency:resolve)
> mvn -B -DskipTests verify ...
> grep -v '^#' ~/.m2/repository/dev/langchain4j/langchain4j-bom/1.13.0/_remote.repositories
> #   langchain4j-bom-1.13.0.pom>central-8fac3ebd6edbaca3c794783fa38088af0aa128e7=
> # 2. add and load the plugin
> jbang -Dcamel.jbang.version=4.22.1 camel@apache/camel plugin add forage --gav io.kaoto.forage:camel-jbang-plugin-forage:<version>
> jbang -Dcamel.jbang.version=4.22.1 camel@apache/camel forage --help
> #   NoClassDefFoundError (plugin classpath = parent pom + plugin jar only)
> {noformat}
> Running step 1 with {{MAVEN_ARGS=-Daether.system.trackingRepositoryKeyFunction=nid}} (legacy tracking) makes step 2 work.
> This hits CI first: GitHub-hosted runners now ship Maven 3.10.0, so any job whose Maven cache is (re)built by Maven 3.10 breaks, while jobs restoring an older cache keep working.
> h3. Suggested fixes
> * Upgrade the Maven Resolver embedded in {{camel-tooling-maven}} to 2.0.23+ (which reads both legacy and URL-qualified tracking entries), or configure the tracking key function of the embedded session accordingly.
> * In {{MavenDownloaderImpl}}, do not treat an offline resolution as successful when the root artifact's descriptor could not be read (or resolved with no dependencies although the POM declares some): fall back to online resolution instead, and avoid caching such a classpath in {{PluginHelper.writeCache}}.
> h3. Workaround
> Set {{-Daether.system.trackingRepositoryKeyFunction=nid}} for the Maven builds that populate the local repository used by Camel JBang (e.g. {{MAVEN_ARGS}} in CI).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)