Luigi De Masi created CAMEL-23470:
-------------------------------------
Summary: camel_version_list MCP tool misses versions released
after the catalog build date
Key: CAMEL-23470
URL: https://issues.apache.org/jira/browse/CAMEL-23470
Project: Camel
Issue Type: Improvement
Components: camel-jbang
Reporter: Luigi De Masi
Assignee: Luigi De Masi
h2. Problem
The {{camel_version_list}} MCP tool relies on a static {{camel-releases.json}}
embedded in the {{camel-catalog}} JAR. This JSON is generated at build time by
{{UpdateCamelReleasesMojo}} and only knows about versions that existed when the
catalog was built.
Versions released after that date — particularly patch releases on older LTS
branches — are missing from the results. For example, when running the Camel
MCP server version 4.20.0 (built 2026-04-25), {{camel_version_list}} would not
return 4.18.2 if that patch was released after the 4.20.0 catalog was generated.
This is a structural limitation: the static JSON files in the catalog will
always lag behind, missing versions released after the MCP server version was
built.
The existing {{download=true}} flag supplements with Maven Central queries to
discover version existence, and the {{onlineRelease()}} fallback
({{VersionList.java}}) fetches metadata from individual release pages on the
camel-website repo for unknown versions. However, this approach has limitations:
* Makes N individual HTTP calls (one per unknown version)
* Depends on the website having published the release page before the tool can
find it
* Spring Boot version pairing is not available in the release page front matter
h2. Proposed Solution (Hybrid approach)
Layer multiple runtime sources in priority order:
*1. Fetch aggregated release JSON at runtime (primary)*
Fetch the full {{camel-releases.json}} from the {{main}} branch of
{{apache/camel}} via a single HTTP GET (e.g., from
{{raw.githubusercontent.com}}). The {{main}} branch JSON is always up-to-date
because {{UpdateCamelReleasesMojo}} runs on every build. Cache the result
locally with a TTL (e.g., 24 hours) to avoid repeated downloads.
*2. Convention-based derivation (gap-filling)*
For versions that Maven Central discovers but the fetched JSON does not
contain, derive metadata from conventions and POM inspection:
* Release date: from Maven Central artifact metadata
* JDK requirement: from major.minor version conventions (e.g., 4.x → 17,21)
* LTS kind: from even-minor convention (4.0, 4.4, 4.8, 4.10, 4.14, 4.18, ...)
* EOL date: LTS release date + 1 year
* Spring Boot version: download the POM of {{camel-spring-boot:X.Y.Z}} and
extract the {{spring-boot.version}} property
* Quarkus pairing: already resolved dynamically via the Quarkus Platform
Registry
*3. Embedded static JSON (offline fallback)*
Use the embedded {{camel-releases.json}} from the catalog JAR as a last resort
when no network is available. This is the current behavior and requires no
changes.
h2. Affected Files
*
{{dsl/camel-jbang/camel-jbang-core/src/main/java/org/apache/camel/dsl/jbang/core/commands/version/VersionList.java}}
*
{{dsl/camel-jbang/camel-jbang-mcp/src/main/java/org/apache/camel/dsl/jbang/core/commands/mcp/VersionTools.java}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
