Claus Ibsen created CAMEL-24761:
-----------------------------------
Summary: camel-jbang - cache the Camel version to Quarkus platform
mapping so --runtime quarkus does not ask the extension registry once a day
Key: CAMEL-24761
URL: https://issues.apache.org/jira/browse/CAMEL-24761
Project: Camel
Issue Type: Improvement
Components: camel-jbang
Reporter: Claus Ibsen
The commands that resolve the Quarkus platform from a Camel version (camel
catalog, camel doc, camel export, camel dependency, and since CAMEL-24711 camel
validate) go through QuarkusHelper.findQuarkusPlatformBom: it fetches
/client/platforms/all from the Quarkus extension registry (registry.quarkus.io)
and picks the platform whose Camel Quarkus lines up with the Camel version. The
response is cached under ~/.camel/quarkus-extension-registries/ and reused when
the file was updated today (QuarkusHelper.updatedToday); --download=false uses
the cached copy regardless of age, --fresh refetches.
So a --runtime quarkus command makes one HTTP call per day. For a released
Camel version the answer never changes once the matching platform is out, so
the daily refetch is wasted, and it is a network hop before a command that is
otherwise offline (a camel validate against a pinned version, in CI).
Proposed:
* Cache the resolved mapping itself, Camel version -> Quarkus platform
(groupId, version, Camel Quarkus version), next to the registry cache, and
reuse it without a TTL for a released Camel version (a version with a final
platform release). Only a Camel version with no platform yet, or the CLI's own
SNAPSHOT version, still consults the registry daily.
* --fresh drops the mapping cache as it drops the registry cache today.
* The Maven side (the quarkus-camel-bom POM, the camel-quarkus-catalog jar, the
camel-yaml-dsl jar) is already cached in ~/.m2 after the first download;
nothing to do there.
Follow-up of CAMEL-24711, where camel validate --runtime quarkus started using
this resolution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
