Federico Mariani created CAMEL-26350:
----------------------------------------
Summary: camel-jbang - plugin update: re-select community plugin
releases for the CLI, run after self-update
Key: CAMEL-26350
URL: https://issues.apache.org/jira/browse/CAMEL-26350
Project: Camel
Issue Type: Improvement
Components: camel-jbang
Reporter: Federico Mariani
h3. Problem
{{camel self-update}} only replaces the CLI. It never touches
{{~/.camel-jbang-plugins.json}}. Since CAMEL-26344, {{camel plugin add}} stores
the exact plugin release built for the CLI (for example
{{io.kaoto.forage:camel-jbang-plugin-forage:1.6.2}} with
{{camelVersions=[4.22.0,4.23.0)}}) instead of {{LATEST}}. After a CLI upgrade:
* the plugin stays on the release built for the previous Camel line
* the load-time check prints {{forage 1.6.2 is built for Camel [4.22.0,4.23.0)
but this CLI is 4.25.0. Run 'camel plugin add forage' ...}}
* the user has to re-add every plugin by hand
New plugin patches (for example Forage 1.6.3) are also no longer picked up
automatically.
Before CAMEL-26344, plugins registered as {{LATEST}} floated after an upgrade
to the newest release, whichever Camel line it was built for.
h3. Proposal
# *{{camel plugin update [name]}}*: for every plugin entry that was
auto-selected, re-run the CAMEL-26344 selection for the running CLI and rewrite
the entry when a different release matches. Auto-selected entries are the ones
with {{camelVersions}} stored; explicit {{--version}} / {{--gav}} registrations
don't store it.
** Print what changed, e.g. {{forage 1.6.2 -> 1.7.0 (built for Camel 4.23.0)}}.
** Resolve the new release before rewriting the entry, so a failed download
leaves the old one in place.
** Explicit registrations, built-in plugins and legacy entries without
{{camelVersions}} are only reported, never changed. A legacy entry gets a hint
to run {{camel plugin add <name>}}.
** No match: keep the current entry and warn, as {{plugin add}} does.
# *{{camel self-update}}* runs the *new* binary's {{camel plugin update}} after
a successful activation. Only the new CLI knows its version and range. Add an
opt-out such as {{--skip-plugins}}. A plugin update failure prints a hint and
never fails or rolls back the CLI update.
# The plugin load path stays as it is: warning only, no network calls.
h3. Example
* Installed: CLI 4.22.3 with Forage 1.6.2 (auto-selected).
* Line pin {{4.22}}: {{camel self-update}} installs 4.22.4. Forage 1.6.2 still
matches, so it is unchanged, or moves to a newer 1.6.x patch if one exists.
* Unpinned: {{camel self-update}} installs 4.25.0, and Forage moves to the
newest release built for 4.25. If none exists yet, it keeps 1.6.2 and warns.
h3. Acceptance criteria
* {{camel plugin update}} and {{camel plugin update <name>}} with the behaviour
above. Entries without any changes are left untouched, byte for byte.
* {{self-update}} invokes it after activation, and {{--skip-plugins}} disables
it. {{--check}} reports the plugin changes that would follow without applying
them, if feasible.
* Works when offline or when repositories are unreachable: warn and keep the
entries.
* Docs: plugin page and self-update page.
* Tests:
** auto-selected entry moved to the new line
** patch update within a line
** no match
** explicit and legacy entries untouched
** download failure keeps the old entry
** self-update hook, plus the opt-out
** a fixture plugin, to keep it generic
h3. Notes
* Builds on CAMEL-26344 (apache/camel#28581) and the release selectors of
CAMEL-26345 (apache/camel#28582).
* On 4.22.x it is useful together with the self-update fixes ([camel-4.22.x]
#28583) and a backport of the CAMEL-26345 self-update selector support.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
