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)