etzel-mes opened a new pull request, #29315: URL: https://github.com/apache/camel/pull/29315
# Description `camel run` and `camel export` asked the Quarkus Extension Registry for the Quarkus Platform also when the runtime is not Quarkus, and stopped when the registry could not be reached ([CAMEL-26673](https://issues.apache.org/jira/browse/CAMEL-26673)). ## Change - `RunPipeline.configure` resolves the Quarkus Platform only for the Quarkus runtime, or when a Quarkus version is given (`--quarkus-version`, `camel.jbang.quarkusVersion`). Any other run looks nothing up. - `QuarkusExporter` leaves the version of `io.quarkus` dependencies to the Quarkus Platform BOM, as for the Camel Quarkus extensions that the BOM manages and for the replacements of `quarkus-dependencies.properties`. It does not check the BOM for them; that would need the `quarkus-bom` POM at every export. A local JAR keeps its version. - `MetadataHelper` of the kubernetes plugin no longer looks the version up. ## Why no lookup is needed With a runtime other than Quarkus the version was only used by `KnownDependenciesResolver`, for the 12 entries of `camel-main-known-dependencies.properties` with the `${quarkus-version}` placeholder. Without a version the resolver leaves the placeholder, and `KnownDependenciesVersionResolver` of the downloader resolves it from the `quarkus-version` property of the `camel-dependencies` POM, as for the other placeholders of that file. `camel-jbang-running.adoc` describes this. Until 4.20 the same property was `RuntimeType.QUARKUS_VERSION`. In `MetadataHelper` the `KnownDependenciesResolver` loads no mappings, and its class resolver is created before the downloader is added to the context, so the version could not be used. The lookup there always went to `registry.quarkus.io`, whatever `--quarkus-ext-registry` or `--quarkus-version` said. ## Why the Quarkus export changes An export without files, without `--fresh` and without an `application.properties` reuses the data of an earlier run, and wrote `io.quarkus:quarkus-core` and the `io.quarkus:quarkus-jdbc-*` drivers into the `pom.xml` with the version of that run. That version can be another one than the platform of the export: a version given only to the export, a platform published in between, and with this change the build-time version of a run with another runtime. The project imports `quarkus-bom`, which manages these artifacts. ## What changes for users - With a runtime other than Quarkus, `io.quarkus:quarkus-core` and the `io.quarkus:quarkus-jdbc-*` drivers get the `quarkus-version` of the `camel-dependencies` POM of the Camel CLI instead of the Quarkus Platform version that the registry has for the Camel version. This is also their version in an exported Camel Main or Spring Boot `pom.xml`. A given Quarkus version is used as before. - The run settings of these runs no longer have `camel.jbang.quarkusGroupId`, `camel.jbang.quarkusVersion` and `camel.jbang.quarkusExtensionRegistryBaseUri`, unless a version is given. This is the whole change in the 39 golden files. I found no reader of these settings in the repository. - An exported Quarkus `pom.xml` has `io.quarkus` dependencies without a version, also one given with `--dep`. An `io.quarkus` artifact that the BOM does not manage then needs its version added in the `pom.xml`. - With the Quarkus runtime, `camel kubernetes export` and `camel kubernetes run` no longer ask `registry.quarkus.io` in addition to the registry or the version that is given. - Nothing else changes for the Quarkus runtime. ## Prior work CAMEL-23560 (#23333) replaced the build-time Quarkus Platform version by the lookup in the registry, also for the in-process run. This change keeps that for the Quarkus runtime. For the other runtimes the 12 known dependencies take the `quarkus-version` property of the `camel-dependencies` POM again, which is a version from build time. If that is not wanted, the alternative is a lookup when one of these dependencies is needed; it needs a supplier through `KameletMain` and `KnownDependenciesResolver`. CAMEL-24724 (#28746) moved the lookup into `RunPipeline`, and with it `camel run --runtime=camel-main` started to ask as well. ## Tests - `QuarkusPlatformLookupTest`: with a registry that cannot be reached, the export to Camel Main and Spring Boot works, also for a source that imports `jakarta.inject.Named`; a given Quarkus version is used; the Quarkus runtime looks its platform up and stops without the registry; a Quarkus export that reuses the data of a Camel Main run has `quarkus-core` without a version. - `RunExportGoldenTest` with the regenerated files. - With the CLI built from this branch and a closed registry: the table in the JIRA comment. ## Please check the whole change The diff is small, but it changes what Camel Main, Spring Boot, Quarkus and the kubernetes plugin share, and I do not know all of that code. I am not sure that I have seen every path that depends on the looked-up version. What I did not verify: - a Maven build of an exported Quarkus project with `io.quarkus` dependencies without a version; - `quarkus-bom` of platforms other than 3.40.1; - readers of the run settings outside this repository; - the root build and the full test suite: I built and tested the three changed modules, against the nightly snapshots. Please review the change as a whole, not only the lines of the diff. ## Not in this pull request The lookup itself is unchanged: `--download=false` without a cache, a cache from an earlier day, an empty answer of the registry and the message of a failed connection. They concern the Quarkus runtime and can go to a ticket of their own. @davsclaus @ppalaga # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. _Claude Code on behalf of etzel-mes_ -- 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]
