[
https://issues.apache.org/jira/browse/CAMEL-26673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18139535#comment-18139535
]
Serdar Gökay commented on CAMEL-26673:
--------------------------------------
While preparing the pull request I looked at who uses the looked-up version,
and found a third way, which needs no lookup for these runtimes.
With a runtime other than Quarkus the version is used only 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 ("Advanced: how a class becomes a dependency" in
camel-jbang-running.adoc). Until 4.20 this property was
{{RuntimeType.QUARKUS_VERSION}}; it is 3.40.1 in 4.23.0 and 3.40.1.1 on main.
Proposed change:
* {{RunPipeline.configure}} resolves the Quarkus Platform only for the Quarkus
runtime, or when a Quarkus version is given. Any other run looks nothing up,
and the 12 dependencies get the version of the camel-dependencies POM.
* The export to Quarkus leaves the version of io.quarkus dependencies to the
Quarkus Platform BOM, as for the Camel Quarkus extensions that the BOM manages.
Today the pom has them with the version of the run. That can already be another
version than the platform of the export (an export without files and without
the fresh option reuses the data of an earlier run), and with the first point
it would be the build-time version after a run with another runtime.
* {{MetadataHelper}} of the kubernetes plugin has the same lookup, always
against registry.quarkus.io. Its {{KnownDependenciesResolver}} loads no
mappings, so the version is not used; the lookup is removed.
The cost: for these runtimes the 12 dependencies have a version from build time
again, which CAMEL-23560 replaced by the registry. If that is not wanted, the
first way of the description (a lookup when one of the 12 dependencies is
needed) is the alternative; I have tried it, it needs a supplier through
{{KameletMain}} and {{KnownDependenciesResolver}}.
This corrects my description: with its second way a dependency that needs the
version would not have failed.
Checked with the CLI built from main with this change, and a closed registry:
||Command||Result||
|camel run, default runtime|starts|
|camel run, a source that imports jakarta.inject.Named|starts,
io.quarkus:quarkus-core:3.40.1.1|
|camel run, quarkus.datasource.db-kind=h2|starts,
io.quarkus:quarkus-jdbc-h2:3.40.1.1|
|camel run, the same source, Quarkus version 3.40.1 given|starts,
io.quarkus:quarkus-core:3.40.1|
|camel export, runtime camel-main|project is written|
|camel export, runtime spring-boot|project is written|
|camel export, runtime quarkus|stops, as before|
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 have not built
an exported Quarkus project with Maven, and I looked at {{quarkus-bom}} of
3.40.1 only. I may have missed a path that depends on the looked-up version, so
please check the change as a whole.
I will open a pull request with this.
_Claude Code on behalf of etzel-mes_
> camel-jbang - camel run and camel export ask the Quarkus Extension Registry
> for runtimes that do not use Quarkus, and stop when it cannot be reached
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26673
> URL: https://issues.apache.org/jira/browse/CAMEL-26673
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
> Affects Versions: 4.23.0
> Reporter: Serdar Gökay
> Assignee: Serdar Gökay
> Priority: Minor
> Fix For: 4.24.0
>
>
> Since 4.21.0 (CAMEL-23560) the Camel CLI finds the Quarkus Platform by asking
> the Quarkus Extension Registry. {{camel run}} and {{camel export}} ask also
> when the runtime is not Quarkus, as one of their first steps, and the command
> stops when the registry cannot be reached. On a machine that cannot reach
> registry.quarkus.io, an integration that uses nothing from Quarkus then does
> not start, and a Camel Main or Spring Boot project is not exported.
> h3. Observed
> Camel CLI 4.23.0 and 4.24.0-SNAPSHOT (nightly 20261105.143830), Java 25. The
> registry is replaced by a closed local port for which no cached answer
> exists, so the cache under {{~/.camel/quarkus-extension-registries}} plays no
> part.
> ||Command||4.23.0||main||
> |camel run, default runtime (in process)|stops, no route is loaded|stops, no
> route is loaded|
> |camel run, runtime camel-main|starts|stops|
> |camel export, runtime camel-main|stops, no project is written|stops, no
> project is written|
> |camel export, runtime spring-boot|stops, no project is written|stops, no
> project is written|
> |camel run, default runtime, with a Quarkus version given|starts|starts|
> |camel export, runtime camel-main, with a Quarkus version given|project is
> written|project is written|
> h3. Reproduce
> hello.yaml:
> {noformat}
> - route:
> id: hello
> from:
> uri: timer:tick
> parameters:
> period: 1000
> steps:
> - log: "ROUTE-RUNNING"
> {noformat}
> {noformat}
> camel run hello.yaml --quarkus-ext-registry=http://127.0.0.1:9
> camel run hello.yaml --runtime=camel-main
> --quarkus-ext-registry=http://127.0.0.1:9
> camel export hello.yaml --runtime=camel-main --gav=com.example:demo:1.0
> --dir=out --quarkus-ext-registry=http://127.0.0.1:9
> camel export hello.yaml --runtime=spring-boot --gav=com.example:demo:1.0
> --dir=out --quarkus-ext-registry=http://127.0.0.1:9
> {noformat}
> The first command on 4.23.0:
> {noformat}
> java.lang.RuntimeException: Could not fetch from
> http://127.0.0.1:9/client/platforms/all
> at
> org.apache.camel.dsl.jbang.core.common.QuarkusHelper.fetchPlatformStreams(QuarkusHelper.java:369)
> at
> org.apache.camel.dsl.jbang.core.common.QuarkusHelper.findQuarkusPlatformBom(QuarkusHelper.java:196)
> at
> org.apache.camel.dsl.jbang.core.common.QuarkusHelper.findQuarkusPlatformBom(QuarkusHelper.java:159)
> at
> org.apache.camel.dsl.jbang.core.commands.QuarkusPlatformMixin.resolve(QuarkusPlatformMixin.java:76)
> at org.apache.camel.dsl.jbang.core.commands.Run.run(Run.java:987)
> {noformat}
> The Spring Boot export on 4.23.0:
> {noformat}
> Generating fresh run data
> java.lang.RuntimeException: Could not fetch from
> http://127.0.0.1:9/client/platforms/all
> at
> org.apache.camel.dsl.jbang.core.common.QuarkusHelper.fetchPlatformStreams(QuarkusHelper.java:369)
> at
> org.apache.camel.dsl.jbang.core.common.QuarkusHelper.findQuarkusPlatformBom(QuarkusHelper.java:196)
> at
> org.apache.camel.dsl.jbang.core.common.QuarkusHelper.findQuarkusPlatformBom(QuarkusHelper.java:159)
> at
> org.apache.camel.dsl.jbang.core.commands.QuarkusPlatformMixin.resolve(QuarkusPlatformMixin.java:76)
> at org.apache.camel.dsl.jbang.core.commands.Run.run(Run.java:987)
> at org.apache.camel.dsl.jbang.core.commands.Run.runExport(Run.java:632)
> at
> org.apache.camel.dsl.jbang.core.commands.ExportBaseCommand.runSilently(ExportBaseCommand.java:615)
> at
> org.apache.camel.dsl.jbang.core.commands.ExportSpringBoot.export(ExportSpringBoot.java:87)
> {noformat}
> h3. What the answer is used for
> With a runtime other than Quarkus the resolved version goes to two places:
> the run settings ({{camel.jbang.quarkusVersion}}, with the group id and the
> registry URI), and {{KnownDependenciesResolver}}, which puts it into the 12
> entries of {{camel-main-known-dependencies.properties}} that end in the
> quarkus-version placeholder, for example:
> {noformat}
> quarkus.datasource.db-kind\=postgresql =
> io.quarkus:quarkus-jdbc-postgresql:${quarkus-version}
> jakarta.inject.Inject = io.quarkus:quarkus-core:${quarkus-version}
> {noformat}
> A route that needs none of these entries does not use the answer.
> h3. Earlier behaviour and discussion
> * In 4.18.5 {{QuarkusHelper.fetchPlatformStreams}} returns null when the
> registry does not answer within 2 seconds, and its callers fall back to the
> build-time version.
> * CAMEL-23560 removed the build-time version, and the fallback went with it.
> The Javadoc of {{fetchPlatformStreams}} still says that null is returned when
> the registry is unreachable.
> * Users without internet access came up on CAMEL-23353 and again in the
> review of [PR #23333|https://github.com/apache/camel/pull/23333]. In that
> review a given Quarkus version and the local cache were named as the way for
> such environments. As I read them, both discussions were about commands that
> need a Quarkus Platform version. The 4.21 and 4.23 upgrade guides and
> CAMEL-24761 describe the lookup for those commands too. I did not find a
> place in JIRA or the pull requests that says the other runtimes should depend
> on the registry.
> h3. On main
> On 4.23.0 {{camel run}} with the camel-main runtime did not ask:
> {{Run.runCamelMain}} created the exporter without a Quarkus platform, so the
> silent run skipped the lookup. On main the export request always has one
> ({{ExportRequest.quarkusPlatform}} is initialised, and
> {{SilentRunDependencyResolver}} passes it to the run request), so this
> command now stops too:
> {noformat}
> Running using Camel Main (preparing and downloading files)
> ERROR: Could not fetch from http://127.0.0.1:9/client/platforms/all
> java.lang.RuntimeException: Could not fetch from
> http://127.0.0.1:9/client/platforms/all
> at
> org.apache.camel.dsl.jbang.run.common.QuarkusHelper.fetchPlatformStreams(QuarkusHelper.java:370)
> at
> org.apache.camel.dsl.jbang.run.common.QuarkusHelper.findQuarkusPlatformBom(QuarkusHelper.java:197)
> at
> org.apache.camel.dsl.jbang.run.common.QuarkusHelper.findQuarkusPlatformBom(QuarkusHelper.java:160)
> at
> org.apache.camel.dsl.jbang.run.common.QuarkusPlatform.resolve(QuarkusPlatform.java:79)
> at
> org.apache.camel.dsl.jbang.run.RunPipeline.configure(RunPipeline.java:486)
> at
> org.apache.camel.dsl.jbang.run.SilentRunDependencyResolver.resolve(SilentRunDependencyResolver.java:86)
> at
> org.apache.camel.dsl.jbang.run.export.Exporter.runSilently(Exporter.java:223)
> at
> org.apache.camel.dsl.jbang.run.export.CamelMainExporter.export(CamelMainExporter.java:81)
> at
> org.apache.camel.dsl.jbang.run.export.ProjectExporter.export(ProjectExporter.java:187)
> at
> org.apache.camel.dsl.jbang.run.CamelMainRunner.start(CamelMainRunner.java:125)
> at
> org.apache.camel.dsl.jbang.run.ProjectRunner.start(ProjectRunner.java:80)
> at
> org.apache.camel.dsl.jbang.core.commands.Run.runWithMaven(Run.java:917)
> at
> org.apache.camel.dsl.jbang.core.commands.Run.runCamelMain(Run.java:908)
> {noformat}
> h3. Proposed change
> Make the command independent of the registry for runtimes other than Quarkus.
> Two ways I can see:
> # resolve the platform only when a dependency with the quarkus-version
> placeholder is needed, or
> # keep the lookup, and when it fails log it and continue without a Quarkus
> version, so that only a dependency that needs the version fails.
> Nothing changes for the Quarkus runtime. I can prepare a pull request; please
> say which way you prefer.
> h3. Workaround
> Give the Quarkus version. With the quarkus-version option the registry is not
> asked (4.23.0 and main); {{camel.jbang.quarkusVersion}} in
> application.properties does the same (checked on 4.23.0).
> {noformat}
> camel run hello.yaml --quarkus-version=3.40.1.1
> --quarkus-ext-registry=http://127.0.0.1:9
> {noformat}
> Filed as Bug because of the change on main for the camel-main runtime. The
> part that exists since 4.21.0 may fit Improvement better; please reclassify
> as you see fit.
> _Claude Code on behalf of etzel-mes_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
