Croway opened a new pull request, #28581: URL: https://github.com/apache/camel/pull/28581
https://issues.apache.org/jira/browse/CAMEL-26344 `camel plugin add <name>` registered community plugins (forage, kit, ...) as Maven `LATEST`, so a CLI could get a plugin release built for another Camel line. For example, CLI 4.23.0 with Forage 1.6.2 fails on `camel run` with `Unsupported runtime jbang`, and now that Forage 1.7.0 (built for 4.23) is out, 4.22 LTS users get 1.7.0. With no `--version` / `--gav`, `plugin add` now walks the plugin's releases newest first (plain `N.N[.N]` versions only, at most 10 POM reads) and selects the first one built for the CLI's version. It takes the supported range from: 1. the POM property `camel.jbang.plugin.camel-versions` (Maven range, e.g. `[4.23.0,4.24.0)`); Forage 1.7.0 declares it 2. otherwise, the minor line of its `org.apache.camel:camel-jbang-core` dependency (`4.22.2` -> `[4.22.0,4.23.0)`), which every existing plugin release already has ``` $ camel plugin add forage # CLI 4.22.x Selected forage 1.6.2 for Camel CLI 4.22.3 (built for Camel 4.22.2) ``` - It stores the exact GAV plus `camelVersions` / `camelVersionsSource` in the plugin entry, after downloading the selected release, so a broken selection never reaches the configuration. - No match, or POMs that can't be read: it warns (with the newest release per Camel line and the `--version` command) and registers `LATEST` as before. It never fails. - `--version` / `--gav` register exactly what was given, with a warning when the release is built for another Camel version. - When a plugin loads, a stored range that excludes the CLI (e.g. after a CLI upgrade) prints a warning suggesting `camel plugin add <name>`. This uses stored data only. Existing registrations without a range are never checked. - Built-in `org.apache.camel` plugins are unchanged. Commits: - `camel-tooling-maven`: `MavenDownloader.resolveArtifactDescriptor`, which returns the resolved POM's dependencies and effective properties through the existing repositories, mirrors, settings and offline handling. - `camel-jbang`: `PluginCompatibility`, `PluginVersionResolver`, the `plugin add` changes and the load-time warning. - docs: "Plugin versions" in `camel-jbang-projects.adoc` (including the property for plugin authors) and the 4.24 upgrade guide. Testing: - New unit tests: `PluginCompatibilityTest`, `PluginVersionResolverTest`, `PluginAddTest`, `PluginHelperTest`, plus `MavenDownloaderImplTest` against a `file://` fixture repo with BOM/parent inheritance. - Full `camel-jbang-core` suite run in a container. The only failures are `ExportMainApplicationProperties`, `DirtyTest` and `ChildProcessTest`, which fail the same way on unmodified main in that environment. - End-to-end with the built launcher in a sandbox (fresh user home per case), using a fixture plugin repo (declared / inferred / unknown / RC versions) and the real Forage and kit releases from Central: | CLI | `camel plugin add forage` (Forage 1.7.0 published) | | --- | --- | | 4.22.3-SNAPSHOT, unmodified | `LATEST` = 1.7.0; Forage itself warns on every command | | 4.22.3-SNAPSHOT with this change | selects 1.6.2 | | 4.24.0-SNAPSHOT with this change | no release declares 4.24 yet: warns and lists `4.23: 1.7.0 / 4.22: 1.6.2 / 4.20: 1.5.0 / 4.18: 1.4.2`, then uses `LATEST` | The backport to camel-4.22.x will follow in a separate PR. -- 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]
