CAMEL-23335: camel-jbang - Lazy plugin discovery and resolved-classpath cache#23129
Conversation
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
|
🧪 CI tested the following changed modules:
💡 Manual integration tests recommended:
All tested modules (6 modules)
|
…th cache Two related changes to remove per-invocation plugin overhead from `camel`: * `CamelJBangMain.execute` now consults a new `PluginHelper.shouldDiscoverPlugins` gate before calling `addPlugins`. Built-in commands that do not consume plugins (e.g. `version`, `get`, `ps`, `stop`) short-circuit the plugin JSON read and FACTORY_FINDER classpath scan entirely. Plugin-consuming built-ins (`run`, `export`, `cmd`, `shell`), unknown subcommands (likely plugin-provided), and no-args/help still discover so plugin commands remain visible. * `PluginHelper.resolvePlugin` now reads a `resolved` block from the per-plugin entry in `~/.camel-jbang-plugins.json`. When present and valid (Camel version, gav, repos match; cached jars and the plugin POM unchanged by size+mtime), the plugin is loaded directly from a URLClassLoader over the cached jars, skipping FACTORY_FINDER and the Maven downloader. The resolved block is populated on the first successful Maven resolution; SNAPSHOT plugins rebuilt locally are picked up automatically via the mtime check. Tests cover the gate's classification, cache hit, mtime-based invalidation, the write path, and a paired before/after demonstration of the cache fast path (no resolved block -> resolver invoked and quits; resolved block present -> plugin loaded from the cached jar without invoking the resolver). The existing `testCacheInvalidatedOnMtimeChange` is cleaned up to use `assertThrows` instead of a try/empty-catch block. Upgrade guide updated. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> rh-pre-commit.version: 2.3.2 rh-pre-commit.check-secrets: ENABLED
|
So I guess this makes this part a little bit faster - especially when you have custom plugins installed like forage |
|
LGTM |
|
@ammachado can you rebase on main and resolve the upgrade guide conflict please? once done, it is good to merge |
I did that, the web editor is okay for some tasks like this |
Description
Two related changes to remove per-invocation plugin overhead from
camel:CamelJBangMain.executenow consults a newPluginHelper.shouldDiscoverPluginsgate before calling
addPlugins. Built-in commands that do not consume plugins(e.g.
version,get,ps,stop) short-circuit the plugin JSON read andFACTORY_FINDER classpath scan entirely. Plugin-consuming built-ins
(
run,export,cmd,shell), unknown subcommands (likely plugin-provided),and no-args/help still discover so plugin commands remain visible.
PluginHelper.resolvePluginnow reads aresolvedblock from the per-pluginentry in
~/.camel-jbang-plugins.json. When present and valid (Camel version,gav, repos match; cached jars and the plugin POM unchanged by size+mtime), the
plugin is loaded directly from a URLClassLoader over the cached jars, skipping
FACTORY_FINDER and the Maven downloader. The resolved block is populated on
the first successful Maven resolution; SNAPSHOT plugins rebuilt locally are
picked up automatically via the mtime check.
Tests cover the gate's classification, cache hit, mtime-based invalidation, the
write path, and a paired before/after demonstration of the cache fast path
(no resolved block -> resolver invoked and quits; resolved block present ->
plugin loaded from the cached jar without invoking the resolver). The existing
testCacheInvalidatedOnMtimeChangeis cleaned up to useassertThrowsinstead of a try/empty-catch block.
Upgrade guide updated.
Co-Authored-By: Claude Opus 4.7 noreply@anthropic.com
Target
mainbranch)Tracking
Apache Camel coding standards and style
mvn clean install -DskipTestslocally from root folder and I have committed all auto-generated changes.