[
https://issues.apache.org/jira/browse/CAMEL-23470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino reassigned CAMEL-23470:
----------------------------------------
Assignee: Andrea Cosentino (was: Luigi De Masi)
> 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
> Affects Versions: 4.20.0
> Reporter: Luigi De Masi
> Assignee: Andrea Cosentino
> Priority: Major
>
> 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)
