You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Luigi De Masi (Jira)" <ji...@apache.org> on 2026/03/13 08:33:00 UTC
[jira] [Created] (CAMEL-23190) [camel-jbang-mcp] DefaultCamelCatalog.getCatalogVersion() ignores VersionManager and returns compiled-in version
Luigi De Masi created CAMEL-23190:
-------------------------------------
Summary: [camel-jbang-mcp] DefaultCamelCatalog.getCatalogVersion() ignores VersionManager and returns compiled-in version
Key: CAMEL-23190
URL: https://issues.apache.org/jira/browse/CAMEL-23190
Project: Camel
Issue Type: Bug
Affects Versions: 4.18.0
Reporter: Luigi De Masi
Assignee: Luigi De Masi
When a different catalog version is loaded via a custom VersionManager (e.g. DownloadCatalogVersionManager or MavenVersionManager), getCatalogVersion() still returns the compiled-in version from pom.properties instead of the loaded version.
Root cause is a circular dependency:
* DefaultCamelCatalog.getCatalogVersion() reads from VersionHelper, which resolves pom.properties via getClass().getResourceAsStream()
* DefaultVersionManager.getLoadedVersion() delegates back to camelCatalog.getCatalogVersion()
* getCatalogVersion() never consults the VersionManager
In an uber-jar (e.g. camel-jbang-mcp), the classloader resolves pom.properties from the uber-jar itself, so getCatalogVersion() always returns the build-time version (e.g. 4.19.0-SNAPSHOT) even after downloading camel-catalog:4.10.0.
we need to break the circular dependency by having DefaultVersionManager use VersionHelper directly, then delegate getCatalogVersion() to versionManager.getLoadedVersion().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)