davsclaus commented on code in PR #27840:
URL: https://github.com/apache/camel/pull/27840#discussion_r4279075690
##########
dsl/camel-jbang/camel-jbang-mcp/src/test/java/org/apache/camel/dsl/jbang/core/commands/mcp/CatalogServiceTest.java:
##########
@@ -176,4 +176,22 @@ void
downloadedCatalogViaPlatformBomVersionDiffersFromBuiltin() {
assertThat(version).isEqualTo(requestedVersion);
assertThat(version).isNotEqualTo(BUILTIN_VERSION);
}
+
+ /**
+ * CAMEL-25640: quarkus runtime with only camelVersion (no explicit
platformBom) used to pass null to
+ * loadQuarkusCatalog, which silently returned an unusable catalog. The
fix resolves the BOM from the registry.
+ * Disabled in CI: requires network access to the Quarkus extension
registry.
+ */
+ @Test
+ @DisabledIfSystemProperty(named = "ci.env.name", matches = ".*",
+ disabledReason = "Runs only local — requires
Quarkus extension registry access")
+ void quarkusRuntimeWithCamelVersionResolvesTheBomFromRegistry() {
+ // CAMEL-25640: passing camelVersion with quarkus runtime must resolve
the platform BOM from the Quarkus
+ // extension registry and pass it to doLoadCatalog; previously it
passed null and produced an NPE or a
+ // silently wrong catalog. Use a released version that is not the
built-in one so sameAsDefault() is false
+ // and the new code path is taken.
+ CatalogService service = createService(null);
+ String result = version(service, "quarkus", "4.10.0", null);
+ assertThat(result).isEqualTo("4.10.0");
Review Comment:
I don't think this can pass locally. A Quarkus catalog reports the CLI's
Camel version here, not 4.10.0:
- `CatalogLoader.loadQuarkusCatalog` loads `DefaultCamelCatalog` through a
`DependencyDownloaderClassLoader` whose parent is the context classloader. Only
the `camel-quarkus-catalog` jar is added to it, so the class comes from the
CLI's own `camel-catalog`.
- That catalog keeps its `DefaultVersionManager`. `getCatalogVersion()` then
comes from `VersionHelper`, which reads the `pom.properties` of the
`camel-catalog` jar that loaded it (4.23.0-SNAPSHOT here).
- Even if it reported the Camel version, `findPlatformBom` matches on
major.minor and takes the newest release of each stream. That is probably a
later 4.10.x, not 4.10.0.
The old `isNotEmpty()` was probably there for this reason. Something that
checks the new path is taken would work, for example:
```java
CamelCatalog catalog = createService(null).loadCatalog("quarkus", "4.10.0",
null);
assertThat(catalog.getRuntimeProvider().getProviderName()).isEqualTo("quarkus");
```
(the method then needs `throws Exception` and the `CamelCatalog` import).
Could @gnodet run it locally once?
##########
docs/user-manual/modules/ROOT/pages/camel-jbang-mcp.adoc:
##########
@@ -475,6 +475,9 @@ the same answer, and the note also says to change the line
the error names. Vali
`content` with a `directory` (the checks then read the other files of the
project, which a fix can change), is
always answered in full.
+A call that fails (the catalog version cannot be downloaded, the file argument
is missing) does not count:
Review Comment:
Small accuracy point. On `camel mcp`, a catalog version that cannot be
downloaded no longer fails. `CatalogService.loadCatalog` (main runtime with a
version) catches the download error and returns the built-in catalog.
`AuthoringTools.call` then hands that catalog to the context, so the answer
comes from the built-in catalog and is counted. Nothing in the answer says that
the requested version could not be loaded. A component answer shows the
artifact `version`, but a model may not notice it. The example only holds for
`camel tui --mcp`, where `ToolContext` still throws `Cannot load the Camel
catalog for version ...`.
Either way is fine with me, but please choose on purpose. One option: drop
the version example here, or say that `camel mcp` answers from its own version.
The other: keep the error for the authoring tools by not falling back in that
path. Also, `AuthoringTools.call`'s `catch` block (and its debug log) is now
only reached in rare cases.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
