Skip to content

chore(deps): Bump kubernetes-client-version from 7.8.0 to 7.9.0 - #26242

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/maven/kubernetes-client-version-7.9.0
Open

chore(deps): Bump kubernetes-client-version from 7.8.0 to 7.9.0#26242
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/maven/kubernetes-client-version-7.9.0

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Sep 9, 2026

Copy link
Copy Markdown
Contributor

Bumps kubernetes-client-version from 7.8.0 to 7.9.0.
Updates io.fabric8:kubernetes-client from 7.8.0 to 7.9.0

Release notes

Sourced from io.fabric8:kubernetes-client's releases.

7.9.0 (2026-09-04)

Bugs

  • Fix #8024: (httpclient-vertx-5) WebSocket operations (exec/attach/portForward/WebSocket-backed watches) on a derived client - one produced by calling newBuilder()/build() on an already-built HttpClient - no longer fall back to Vert.x's bare WebSocketClient defaults. Vertx5HttpClientBuilder.build()'s short-circuit path for derived clients reused the original client's plain HTTP connection (with its configuration intact) but always created a brand-new WebSocketClient with no options at all, discarding both the trust/key material (so TLS verified against the JVM default trust store instead of the configured cluster CA) and the configured limits (maxFrameSize/maxMessageSize fell back to 64 KiB/256 KiB instead of unlimited, and maxConnections to 50 instead of 8192, so oversized exec/attach messages were silently dropped even on plain HTTP). This affects kubernetes-httpclient-vertx-5 only, which is opt-in - the bundled default kubernetes-httpclient-vertx (Vert.x 4) serves WebSockets from the same client it reuses when deriving and was never affected - and it is present in 7.6.0 through 7.8.0. Derivation happens more often than it looks: OpenShiftClientImpl derives on every adapt(OpenShiftClient.class) to install its OAuth token-refresh interceptor, OpenShiftOAuthInterceptor derives on every token refresh, and BaseClient#newClient derives whenever a differing RequestConfig is set. Derived clients now reuse the original's WebSocketClient outright, the same way they already reused its HTTP client, so they can no longer drift from it and no second transport is allocated per derivation. Note that sharing the transport also means closing any client in a derived family closes it for the whole family: close() on a client obtained from adapt(OpenShiftClient.class) now ends WebSocket operations on the client it was derived from as well, which is already what happened to that client's HTTP requests and what the other four implementations do. Nothing usable is lost, since the original's HTTP client was closed regardless; what changes is that the per-derivation WebSocketClient is no longer left behind unclosed
  • Fix #8029: (httpclient-vertx-5, httpclient-jetty) WebSocket connections now honor the configured proxy, so exec/attach/portForward and WebSocket-backed watches no longer connect straight to the API server and bypass a mandated egress proxy. Both implementations serve WebSockets from a transport separate from the HTTP client (a Vert.x 5 WebSocketClient, and a second Jetty HttpClient behind the WebSocketClient) and neither was given the proxy configuration; Jetty's WebSocket transport now also receives the proxy BasicAuthentication entry. The OkHttp, JDK and Vert.x 4 modules were unaffected because a single client serves both. On httpclient-vertx-5 the configured connect timeout was not applied to the WebSocket client either, so a WebSocket connect could hang well past it. One consequence worth calling out: when the proxy credentials cannot be decoded - HttpClientUtils.decodeBasicCredentials returns null for anything that is not Basic, or whose decoded value does not split into exactly two :-separated parts, so a proxy password containing a colon is enough - the client falls back to stamping Proxy-Authorization on the request instead of configuring it on the transport. Such WebSocket connections now reach the proxy and are rejected with a 407 rather than silently completing straight to the API server, so a setup that appeared to work only because it was bypassing the proxy will now fail
  • Fix #7807: (kube-api-test) The KUBE_API_TEST_STARTUP_TIMEOUT environment variable is now parsed instead of throwing ClassCastException on every use — the value (always a String) was passed to Class.cast() for an Integer/Boolean target, which only widens reference types and never parses, so the timeout could not be configured via environment at all. A new startupTimeout attribute on @EnableKubeAPIServer (e.g. @EnableKubeAPIServer(startupTimeout = 180000)) allows overriding it declaratively, and all three configuration paths (annotation, builder, env var) now reject non-positive values
  • Fix #7983: (mockwebserver) WebSocket upgrades are now performed synchronously from the Vert.x request handler instead of from the asynchronous HttpServerRequest#body() callback. Deferring the upgrade let the request end event be processed first, so HttpServerRequest#toWebSocket() intermittently threw IllegalStateException: Request has already been read and the upgrade was lost (surfacing as flaky exec/attach mock-server tests). Upgrade requests carry no body, so they are detected via the Upgrade header and upgraded before the request is read; the asynchronous path is unchanged for regular HTTP requests
  • Fix #7955: (java-generator) Malicious CRD schema values can no longer inject executable code into the generated Java sources. Schema-controlled values (enum values, CRD group/version/names, property names, descriptions and defaults) are emitted as fully escaped Java string literals, so a value carrying a Unicode-escaped quote cannot break out of its literal once javac decodes it. As a defense in depth, each generated class is also re-parsed and structurally validated before it is written (with Java Unicode escape preprocessing enabled to match javac), aborting generation on any residual structural mismatch
  • Fix #8028: (openshift-model, kube-api-test) No package is shipped by two artifacts anymore, so each pair can be placed on the JPMS module path together. openshift-model no longer bundles the io.fabric8.openshift.api.model.config.* classes that openshift-model-config owns (its Export-Package wildcard inlined them from that dependency); they still reach consumers through it. Fabric8ClientInjectionHandler moved to io.fabric8.kubeapitest.junit.inject

Improvements

Dependency Upgrade

  • Fix #8033: bump gateway-api from 1.5.1 to 1.6.1

New Features

  • Fix #7752: Support for Kubernetes v1.37.0 (Garhwal)
  • Fix #8033: gateway-api model gains v1.TCPRoute and v1.UDPRoute (both graduated from v1alpha2 upstream in gateway-api v1.6.0). The v1alpha2 types remain available, but upstream has deprecated them and will remove them in a future release, so new code should use the v1 types

Note: Breaking changes

  • Fix #7752: Kubernetes model API removals (removed upstream in Kubernetes v1.37.0). The following API versions have been completely removed from Kubernetes and are no longer available in the client:
    • certificates.k8s.io/v1alpha1/ClusterTrustBundle → use certificates.k8s.io/v1 or v1beta1
    • networking.k8s.io/v1beta1/IPAddress → use networking.k8s.io/v1
    • networking.k8s.io/v1beta1/ServiceCIDR → use networking.k8s.io/v1
    • storage.k8s.io/v1beta1/VolumeAttributesClass → use storage.k8s.io/v1
    • scheduling.k8s.io/v1alpha2 (entire API version, 28 types) → use v1alpha3 or v1beta1
  • Fix #7752: VolumeMount constructor signature changed (Kubernetes v1.37.0 added bindMountOptions field). The canonical constructor now takes bindMountOptions (List) as its first parameter. Builder usage (new VolumeMountBuilder().with...()) is unaffected
  • Fix #8033: gateway-api model v1.SessionPersistence no longer exposes idleTimeout (removed upstream in gateway-api v1.6.0). Besides the field, this removes getIdleTimeout()/setIdleTimeout(), collapses the canonical constructor from five arguments to four, and drops SessionPersistenceFluent.withIdleTimeout()/getIdleTimeout()/hasIdleTimeout(), so the builder form (withNewSessionPersistence().withIdleTimeout(...)) no longer compiles. There is no runtime data loss: the class keeps its @JsonAnyGetter/@JsonAnySetter, and both the fluent and the builder carry additionalProperties through, so JSON or YAML still containing idleTimeout continues to deserialize and re-serialize intact
  • Fix #8028: (kube-api-test) Fabric8ClientInjectionHandler moved to io.fabric8.kubeapitest.junit.inject. It is resolved through ServiceLoader, so only code naming the class directly is affected
  • Fix #8028: (openshift-model) The bundle no longer exports or contains io.fabric8.openshift.api.model.config.*. Maven consumers are unaffected (openshift-model-config is a compile dependency), but OSGi deployments importing those packages must install the openshift-model-config bundle, which the openshift-client Karaf feature already does

New Contributors

Full Changelog: fabric8io/kubernetes-client@v7.8.0...v7.9.0

Changelog

Sourced from io.fabric8:kubernetes-client's changelog.

7.9.0 (2026-09-04)

Bugs

  • Fix #8024: (httpclient-vertx-5) WebSocket operations (exec/attach/portForward/WebSocket-backed watches) on a derived client - one produced by calling newBuilder()/build() on an already-built HttpClient - no longer fall back to Vert.x's bare WebSocketClient defaults. Vertx5HttpClientBuilder.build()'s short-circuit path for derived clients reused the original client's plain HTTP connection (with its configuration intact) but always created a brand-new WebSocketClient with no options at all, discarding both the trust/key material (so TLS verified against the JVM default trust store instead of the configured cluster CA) and the configured limits (maxFrameSize/maxMessageSize fell back to 64 KiB/256 KiB instead of unlimited, and maxConnections to 50 instead of 8192, so oversized exec/attach messages were silently dropped even on plain HTTP). This affects kubernetes-httpclient-vertx-5 only, which is opt-in - the bundled default kubernetes-httpclient-vertx (Vert.x 4) serves WebSockets from the same client it reuses when deriving and was never affected - and it is present in 7.6.0 through 7.8.0. Derivation happens more often than it looks: OpenShiftClientImpl derives on every adapt(OpenShiftClient.class) to install its OAuth token-refresh interceptor, OpenShiftOAuthInterceptor derives on every token refresh, and BaseClient#newClient derives whenever a differing RequestConfig is set. Derived clients now reuse the original's WebSocketClient outright, the same way they already reused its HTTP client, so they can no longer drift from it and no second transport is allocated per derivation. Note that sharing the transport also means closing any client in a derived family closes it for the whole family: close() on a client obtained from adapt(OpenShiftClient.class) now ends WebSocket operations on the client it was derived from as well, which is already what happened to that client's HTTP requests and what the other four implementations do. Nothing usable is lost, since the original's HTTP client was closed regardless; what changes is that the per-derivation WebSocketClient is no longer left behind unclosed
  • Fix #8029: (httpclient-vertx-5, httpclient-jetty) WebSocket connections now honor the configured proxy, so exec/attach/portForward and WebSocket-backed watches no longer connect straight to the API server and bypass a mandated egress proxy. Both implementations serve WebSockets from a transport separate from the HTTP client (a Vert.x 5 WebSocketClient, and a second Jetty HttpClient behind the WebSocketClient) and neither was given the proxy configuration; Jetty's WebSocket transport now also receives the proxy BasicAuthentication entry. The OkHttp, JDK and Vert.x 4 modules were unaffected because a single client serves both. On httpclient-vertx-5 the configured connect timeout was not applied to the WebSocket client either, so a WebSocket connect could hang well past it. One consequence worth calling out: when the proxy credentials cannot be decoded - HttpClientUtils.decodeBasicCredentials returns null for anything that is not Basic, or whose decoded value does not split into exactly two :-separated parts, so a proxy password containing a colon is enough - the client falls back to stamping Proxy-Authorization on the request instead of configuring it on the transport. Such WebSocket connections now reach the proxy and are rejected with a 407 rather than silently completing straight to the API server, so a setup that appeared to work only because it was bypassing the proxy will now fail
  • Fix #7807: (kube-api-test) The KUBE_API_TEST_STARTUP_TIMEOUT environment variable is now parsed instead of throwing ClassCastException on every use — the value (always a String) was passed to Class.cast() for an Integer/Boolean target, which only widens reference types and never parses, so the timeout could not be configured via environment at all. A new startupTimeout attribute on @EnableKubeAPIServer (e.g. @EnableKubeAPIServer(startupTimeout = 180000)) allows overriding it declaratively, and all three configuration paths (annotation, builder, env var) now reject non-positive values
  • Fix #7983: (mockwebserver) WebSocket upgrades are now performed synchronously from the Vert.x request handler instead of from the asynchronous HttpServerRequest#body() callback. Deferring the upgrade let the request end event be processed first, so HttpServerRequest#toWebSocket() intermittently threw IllegalStateException: Request has already been read and the upgrade was lost (surfacing as flaky exec/attach mock-server tests). Upgrade requests carry no body, so they are detected via the Upgrade header and upgraded before the request is read; the asynchronous path is unchanged for regular HTTP requests
  • Fix #7955: (java-generator) Malicious CRD schema values can no longer inject executable code into the generated Java sources. Schema-controlled values (enum values, CRD group/version/names, property names, descriptions and defaults) are emitted as fully escaped Java string literals, so a value carrying a Unicode-escaped quote cannot break out of its literal once javac decodes it. As a defense in depth, each generated class is also re-parsed and structurally validated before it is written (with Java Unicode escape preprocessing enabled to match javac), aborting generation on any residual structural mismatch
  • Fix #8028: (openshift-model, kube-api-test) No package is shipped by two artifacts anymore, so each pair can be placed on the JPMS module path together. openshift-model no longer bundles the io.fabric8.openshift.api.model.config.* classes that openshift-model-config owns (its Export-Package wildcard inlined them from that dependency); they still reach consumers through it. Fabric8ClientInjectionHandler moved to io.fabric8.kubeapitest.junit.inject

Improvements

Dependency Upgrade

  • Fix #8033: bump gateway-api from 1.5.1 to 1.6.1

New Features

  • Fix #7752: Support for Kubernetes v1.37.0 (Garhwal)
  • Fix #8033: gateway-api model gains v1.TCPRoute and v1.UDPRoute (both graduated from v1alpha2 upstream in gateway-api v1.6.0). The v1alpha2 types remain available, but upstream has deprecated them and will remove them in a future release, so new code should use the v1 types

Note: Breaking changes

  • Fix #7752: Kubernetes model API removals (removed upstream in Kubernetes v1.37.0). The following API versions have been completely removed from Kubernetes and are no longer available in the client:
    • certificates.k8s.io/v1alpha1/ClusterTrustBundle → use certificates.k8s.io/v1 or v1beta1
    • networking.k8s.io/v1beta1/IPAddress → use networking.k8s.io/v1
    • networking.k8s.io/v1beta1/ServiceCIDR → use networking.k8s.io/v1
    • storage.k8s.io/v1beta1/VolumeAttributesClass → use storage.k8s.io/v1
    • scheduling.k8s.io/v1alpha2 (entire API version, 28 types) → use v1alpha3 or v1beta1
  • Fix #7752: VolumeMount constructor signature changed (Kubernetes v1.37.0 added bindMountOptions field). The canonical constructor now takes bindMountOptions (List) as its first parameter. Builder usage (new VolumeMountBuilder().with...()) is unaffected
  • Fix #8033: gateway-api model v1.SessionPersistence no longer exposes idleTimeout (removed upstream in gateway-api v1.6.0). Besides the field, this removes getIdleTimeout()/setIdleTimeout(), collapses the canonical constructor from five arguments to four, and drops SessionPersistenceFluent.withIdleTimeout()/getIdleTimeout()/hasIdleTimeout(), so the builder form (withNewSessionPersistence().withIdleTimeout(...)) no longer compiles. There is no runtime data loss: the class keeps its @JsonAnyGetter/@JsonAnySetter, and both the fluent and the builder carry additionalProperties through, so JSON or YAML still containing idleTimeout continues to deserialize and re-serialize intact
  • Fix #8028: (kube-api-test) Fabric8ClientInjectionHandler moved to io.fabric8.kubeapitest.junit.inject. It is resolved through ServiceLoader, so only code naming the class directly is affected
  • Fix #8028: (openshift-model) The bundle no longer exports or contains io.fabric8.openshift.api.model.config.*. Maven consumers are unaffected (openshift-model-config is a compile dependency), but OSGi deployments importing those packages must install the openshift-model-config bundle, which the openshift-client Karaf feature already does
Commits
  • c6d4ff3 [RELEASE] Updated project version to v7.9.0
  • feced2a feat(openapi): support for Kubernetes v1.37 (Garhwal) (#7752)
  • 45be75f chore(deps): bump actions/setup-java in the github-actions group
  • 8ba02fc chore(deps): tidy go.sum and expand gateway-api changelog (8033)
  • 687d91e chore(deps): bump gateway-api from 1.5.1 to 1.6.1
  • ceb9218 fix(httpclient): WebSocket transport reuse on derived clients and proxy suppo...
  • c641839 fix(httpclient-vertx-5): trust configured certificate for WebSocket on derive...
  • a2864e1 fix: eliminate split packages in openshift-model and kube-api-test (7986) (8028)
  • 10b8f98 chore(deps): bump org.apache.groovy:groovy-all from 5.0.7 to 5.0.8
  • 91e8b76 chore(deps): bump io.swagger.parser.v3:swagger-parser
  • Additional commits viewable in compare view

Updates io.fabric8:openshift-client from 7.8.0 to 7.9.0

Release notes

Sourced from io.fabric8:openshift-client's releases.

7.9.0 (2026-09-04)

Bugs

  • Fix #8024: (httpclient-vertx-5) WebSocket operations (exec/attach/portForward/WebSocket-backed watches) on a derived client - one produced by calling newBuilder()/build() on an already-built HttpClient - no longer fall back to Vert.x's bare WebSocketClient defaults. Vertx5HttpClientBuilder.build()'s short-circuit path for derived clients reused the original client's plain HTTP connection (with its configuration intact) but always created a brand-new WebSocketClient with no options at all, discarding both the trust/key material (so TLS verified against the JVM default trust store instead of the configured cluster CA) and the configured limits (maxFrameSize/maxMessageSize fell back to 64 KiB/256 KiB instead of unlimited, and maxConnections to 50 instead of 8192, so oversized exec/attach messages were silently dropped even on plain HTTP). This affects kubernetes-httpclient-vertx-5 only, which is opt-in - the bundled default kubernetes-httpclient-vertx (Vert.x 4) serves WebSockets from the same client it reuses when deriving and was never affected - and it is present in 7.6.0 through 7.8.0. Derivation happens more often than it looks: OpenShiftClientImpl derives on every adapt(OpenShiftClient.class) to install its OAuth token-refresh interceptor, OpenShiftOAuthInterceptor derives on every token refresh, and BaseClient#newClient derives whenever a differing RequestConfig is set. Derived clients now reuse the original's WebSocketClient outright, the same way they already reused its HTTP client, so they can no longer drift from it and no second transport is allocated per derivation. Note that sharing the transport also means closing any client in a derived family closes it for the whole family: close() on a client obtained from adapt(OpenShiftClient.class) now ends WebSocket operations on the client it was derived from as well, which is already what happened to that client's HTTP requests and what the other four implementations do. Nothing usable is lost, since the original's HTTP client was closed regardless; what changes is that the per-derivation WebSocketClient is no longer left behind unclosed
  • Fix #8029: (httpclient-vertx-5, httpclient-jetty) WebSocket connections now honor the configured proxy, so exec/attach/portForward and WebSocket-backed watches no longer connect straight to the API server and bypass a mandated egress proxy. Both implementations serve WebSockets from a transport separate from the HTTP client (a Vert.x 5 WebSocketClient, and a second Jetty HttpClient behind the WebSocketClient) and neither was given the proxy configuration; Jetty's WebSocket transport now also receives the proxy BasicAuthentication entry. The OkHttp, JDK and Vert.x 4 modules were unaffected because a single client serves both. On httpclient-vertx-5 the configured connect timeout was not applied to the WebSocket client either, so a WebSocket connect could hang well past it. One consequence worth calling out: when the proxy credentials cannot be decoded - HttpClientUtils.decodeBasicCredentials returns null for anything that is not Basic, or whose decoded value does not split into exactly two :-separated parts, so a proxy password containing a colon is enough - the client falls back to stamping Proxy-Authorization on the request instead of configuring it on the transport. Such WebSocket connections now reach the proxy and are rejected with a 407 rather than silently completing straight to the API server, so a setup that appeared to work only because it was bypassing the proxy will now fail
  • Fix #7807: (kube-api-test) The KUBE_API_TEST_STARTUP_TIMEOUT environment variable is now parsed instead of throwing ClassCastException on every use — the value (always a String) was passed to Class.cast() for an Integer/Boolean target, which only widens reference types and never parses, so the timeout could not be configured via environment at all. A new startupTimeout attribute on @EnableKubeAPIServer (e.g. @EnableKubeAPIServer(startupTimeout = 180000)) allows overriding it declaratively, and all three configuration paths (annotation, builder, env var) now reject non-positive values
  • Fix #7983: (mockwebserver) WebSocket upgrades are now performed synchronously from the Vert.x request handler instead of from the asynchronous HttpServerRequest#body() callback. Deferring the upgrade let the request end event be processed first, so HttpServerRequest#toWebSocket() intermittently threw IllegalStateException: Request has already been read and the upgrade was lost (surfacing as flaky exec/attach mock-server tests). Upgrade requests carry no body, so they are detected via the Upgrade header and upgraded before the request is read; the asynchronous path is unchanged for regular HTTP requests
  • Fix #7955: (java-generator) Malicious CRD schema values can no longer inject executable code into the generated Java sources. Schema-controlled values (enum values, CRD group/version/names, property names, descriptions and defaults) are emitted as fully escaped Java string literals, so a value carrying a Unicode-escaped quote cannot break out of its literal once javac decodes it. As a defense in depth, each generated class is also re-parsed and structurally validated before it is written (with Java Unicode escape preprocessing enabled to match javac), aborting generation on any residual structural mismatch
  • Fix #8028: (openshift-model, kube-api-test) No package is shipped by two artifacts anymore, so each pair can be placed on the JPMS module path together. openshift-model no longer bundles the io.fabric8.openshift.api.model.config.* classes that openshift-model-config owns (its Export-Package wildcard inlined them from that dependency); they still reach consumers through it. Fabric8ClientInjectionHandler moved to io.fabric8.kubeapitest.junit.inject

Improvements

Dependency Upgrade

  • Fix #8033: bump gateway-api from 1.5.1 to 1.6.1

New Features

  • Fix #7752: Support for Kubernetes v1.37.0 (Garhwal)
  • Fix #8033: gateway-api model gains v1.TCPRoute and v1.UDPRoute (both graduated from v1alpha2 upstream in gateway-api v1.6.0). The v1alpha2 types remain available, but upstream has deprecated them and will remove them in a future release, so new code should use the v1 types

Note: Breaking changes

  • Fix #7752: Kubernetes model API removals (removed upstream in Kubernetes v1.37.0). The following API versions have been completely removed from Kubernetes and are no longer available in the client:
    • certificates.k8s.io/v1alpha1/ClusterTrustBundle → use certificates.k8s.io/v1 or v1beta1
    • networking.k8s.io/v1beta1/IPAddress → use networking.k8s.io/v1
    • networking.k8s.io/v1beta1/ServiceCIDR → use networking.k8s.io/v1
    • storage.k8s.io/v1beta1/VolumeAttributesClass → use storage.k8s.io/v1
    • scheduling.k8s.io/v1alpha2 (entire API version, 28 types) → use v1alpha3 or v1beta1
  • Fix #7752: VolumeMount constructor signature changed (Kubernetes v1.37.0 added bindMountOptions field). The canonical constructor now takes bindMountOptions (List) as its first parameter. Builder usage (new VolumeMountBuilder().with...()) is unaffected
  • Fix #8033: gateway-api model v1.SessionPersistence no longer exposes idleTimeout (removed upstream in gateway-api v1.6.0). Besides the field, this removes getIdleTimeout()/setIdleTimeout(), collapses the canonical constructor from five arguments to four, and drops SessionPersistenceFluent.withIdleTimeout()/getIdleTimeout()/hasIdleTimeout(), so the builder form (withNewSessionPersistence().withIdleTimeout(...)) no longer compiles. There is no runtime data loss: the class keeps its @JsonAnyGetter/@JsonAnySetter, and both the fluent and the builder carry additionalProperties through, so JSON or YAML still containing idleTimeout continues to deserialize and re-serialize intact
  • Fix #8028: (kube-api-test) Fabric8ClientInjectionHandler moved to io.fabric8.kubeapitest.junit.inject. It is resolved through ServiceLoader, so only code naming the class directly is affected
  • Fix #8028: (openshift-model) The bundle no longer exports or contains io.fabric8.openshift.api.model.config.*. Maven consumers are unaffected (openshift-model-config is a compile dependency), but OSGi deployments importing those packages must install the openshift-model-config bundle, which the openshift-client Karaf feature already does

New Contributors

Full Changelog: fabric8io/kubernetes-client@v7.8.0...v7.9.0

Changelog

Sourced from io.fabric8:openshift-client's changelog.

7.9.0 (2026-09-04)

Bugs

  • Fix #8024: (httpclient-vertx-5) WebSocket operations (exec/attach/portForward/WebSocket-backed watches) on a derived client - one produced by calling newBuilder()/build() on an already-built HttpClient - no longer fall back to Vert.x's bare WebSocketClient defaults. Vertx5HttpClientBuilder.build()'s short-circuit path for derived clients reused the original client's plain HTTP connection (with its configuration intact) but always created a brand-new WebSocketClient with no options at all, discarding both the trust/key material (so TLS verified against the JVM default trust store instead of the configured cluster CA) and the configured limits (maxFrameSize/maxMessageSize fell back to 64 KiB/256 KiB instead of unlimited, and maxConnections to 50 instead of 8192, so oversized exec/attach messages were silently dropped even on plain HTTP). This affects kubernetes-httpclient-vertx-5 only, which is opt-in - the bundled default kubernetes-httpclient-vertx (Vert.x 4) serves WebSockets from the same client it reuses when deriving and was never affected - and it is present in 7.6.0 through 7.8.0. Derivation happens more often than it looks: OpenShiftClientImpl derives on every adapt(OpenShiftClient.class) to install its OAuth token-refresh interceptor, OpenShiftOAuthInterceptor derives on every token refresh, and BaseClient#newClient derives whenever a differing RequestConfig is set. Derived clients now reuse the original's WebSocketClient outright, the same way they already reused its HTTP client, so they can no longer drift from it and no second transport is allocated per derivation. Note that sharing the transport also means closing any client in a derived family closes it for the whole family: close() on a client obtained from adapt(OpenShiftClient.class) now ends WebSocket operations on the client it was derived from as well, which is already what happened to that client's HTTP requests and what the other four implementations do. Nothing usable is lost, since the original's HTTP client was closed regardless; what changes is that the per-derivation WebSocketClient is no longer left behind unclosed
  • Fix #8029: (httpclient-vertx-5, httpclient-jetty) WebSocket connections now honor the configured proxy, so exec/attach/portForward and WebSocket-backed watches no longer connect straight to the API server and bypass a mandated egress proxy. Both implementations serve WebSockets from a transport separate from the HTTP client (a Vert.x 5 WebSocketClient, and a second Jetty HttpClient behind the WebSocketClient) and neither was given the proxy configuration; Jetty's WebSocket transport now also receives the proxy BasicAuthentication entry. The OkHttp, JDK and Vert.x 4 modules were unaffected because a single client serves both. On httpclient-vertx-5 the configured connect timeout was not applied to the WebSocket client either, so a WebSocket connect could hang well past it. One consequence worth calling out: when the proxy credentials cannot be decoded - HttpClientUtils.decodeBasicCredentials returns null for anything that is not Basic, or whose decoded value does not split into exactly two :-separated parts, so a proxy password containing a colon is enough - the client falls back to stamping Proxy-Authorization on the request instead of configuring it on the transport. Such WebSocket connections now reach the proxy and are rejected with a 407 rather than silently completing straight to the API server, so a setup that appeared to work only because it was bypassing the proxy will now fail
  • Fix #7807: (kube-api-test) The KUBE_API_TEST_STARTUP_TIMEOUT environment variable is now parsed instead of throwing ClassCastException on every use — the value (always a String) was passed to Class.cast() for an Integer/Boolean target, which only widens reference types and never parses, so the timeout could not be configured via environment at all. A new startupTimeout attribute on @EnableKubeAPIServer (e.g. @EnableKubeAPIServer(startupTimeout = 180000)) allows overriding it declaratively, and all three configuration paths (annotation, builder, env var) now reject non-positive values
  • Fix #7983: (mockwebserver) WebSocket upgrades are now performed synchronously from the Vert.x request handler instead of from the asynchronous HttpServerRequest#body() callback. Deferring the upgrade let the request end event be processed first, so HttpServerRequest#toWebSocket() intermittently threw IllegalStateException: Request has already been read and the upgrade was lost (surfacing as flaky exec/attach mock-server tests). Upgrade requests carry no body, so they are detected via the Upgrade header and upgraded before the request is read; the asynchronous path is unchanged for regular HTTP requests
  • Fix #7955: (java-generator) Malicious CRD schema values can no longer inject executable code into the generated Java sources. Schema-controlled values (enum values, CRD group/version/names, property names, descriptions and defaults) are emitted as fully escaped Java string literals, so a value carrying a Unicode-escaped quote cannot break out of its literal once javac decodes it. As a defense in depth, each generated class is also re-parsed and structurally validated before it is written (with Java Unicode escape preprocessing enabled to match javac), aborting generation on any residual structural mismatch
  • Fix #8028: (openshift-model, kube-api-test) No package is shipped by two artifacts anymore, so each pair can be placed on the JPMS module path together. openshift-model no longer bundles the io.fabric8.openshift.api.model.config.* classes that openshift-model-config owns (its Export-Package wildcard inlined them from that dependency); they still reach consumers through it. Fabric8ClientInjectionHandler moved to io.fabric8.kubeapitest.junit.inject

Improvements

Dependency Upgrade

  • Fix #8033: bump gateway-api from 1.5.1 to 1.6.1

New Features

  • Fix #7752: Support for Kubernetes v1.37.0 (Garhwal)
  • Fix #8033: gateway-api model gains v1.TCPRoute and v1.UDPRoute (both graduated from v1alpha2 upstream in gateway-api v1.6.0). The v1alpha2 types remain available, but upstream has deprecated them and will remove them in a future release, so new code should use the v1 types

Note: Breaking changes

  • Fix #7752: Kubernetes model API removals (removed upstream in Kubernetes v1.37.0). The following API versions have been completely removed from Kubernetes and are no longer available in the client:
    • certificates.k8s.io/v1alpha1/ClusterTrustBundle → use certificates.k8s.io/v1 or v1beta1
    • networking.k8s.io/v1beta1/IPAddress → use networking.k8s.io/v1
    • networking.k8s.io/v1beta1/ServiceCIDR → use networking.k8s.io/v1
    • storage.k8s.io/v1beta1/VolumeAttributesClass → use storage.k8s.io/v1
    • scheduling.k8s.io/v1alpha2 (entire API version, 28 types) → use v1alpha3 or v1beta1
  • Fix #7752: VolumeMount constructor signature changed (Kubernetes v1.37.0 added bindMountOptions field). The canonical constructor now takes bindMountOptions (List) as its first parameter. Builder usage (new VolumeMountBuilder().with...()) is unaffected
  • Fix #8033: gateway-api model v1.SessionPersistence no longer exposes idleTimeout (removed upstream in gateway-api v1.6.0). Besides the field, this removes getIdleTimeout()/setIdleTimeout(), collapses the canonical constructor from five arguments to four, and drops SessionPersistenceFluent.withIdleTimeout()/getIdleTimeout()/hasIdleTimeout(), so the builder form (withNewSessionPersistence().withIdleTimeout(...)) no longer compiles. There is no runtime data loss: the class keeps its @JsonAnyGetter/@JsonAnySetter, and both the fluent and the builder carry additionalProperties through, so JSON or YAML still containing idleTimeout continues to deserialize and re-serialize intact
  • Fix #8028: (kube-api-test) Fabric8ClientInjectionHandler moved to io.fabric8.kubeapitest.junit.inject. It is resolved through ServiceLoader, so only code naming the class directly is affected
  • Fix #8028: (openshift-model) The bundle no longer exports or contains io.fabric8.openshift.api.model.config.*. Maven consumers are unaffected (openshift-model-config is a compile dependency), but OSGi deployments importing those packages must install the openshift-model-config bundle, which the openshift-client Karaf feature already does
Commits
  • c6d4ff3 [RELEASE] Updated project version to v7.9.0
  • feced2a feat(openapi): support for Kubernetes v1.37 (Garhwal) (#7752)
  • 45be75f chore(deps): bump actions/setup-java in the github-actions group
  • 8ba02fc chore(deps): tidy go.sum and expand gateway-api changelog (8033)
  • 687d91e chore(deps): bump gateway-api from 1.5.1 to 1.6.1
  • ceb9218 fix(httpclient): WebSocket transport reuse on derived clients and proxy suppo...
  • c641839 fix(httpclient-vertx-5): trust configured certificate for WebSocket on derive...
  • a2864e1 fix: eliminate split packages in openshift-model and kube-api-test (7986) (8028)
  • 10b8f98 chore(deps): bump org.apache.groovy:groovy-all from 5.0.7 to 5.0.8
  • 91e8b76 chore(deps): bump io.swagger.parser.v3:swagger-parser
  • Additional commits viewable in compare view

Updates io.fabric8:kubernetes-server-mock from 7.8.0 to 7.9.0

Updates io.fabric8:mockwebserver from 7.8.0 to 7.9.0

Updates io.fabric8:kubernetes-httpclient-vertx from 7.8.0 to 7.9.0

Release notes

Sourced from io.fabric8:kubernetes-httpclient-vertx's releases.

7.9.0 (2026-09-04)

Bugs

  • Fix #8024: (httpclient-vertx-5) WebSocket operations (exec/attach/portForward/WebSocket-backed watches) on a derived client - one produced by calling newBuilder()/build() on an already-built HttpClient - no longer fall back to Vert.x's bare WebSocketClient defaults. Vertx5HttpClientBuilder.build()'s short-circuit path for derived clients reused the original client's plain HTTP connection (with its configuration intact) but always created a brand-new WebSocketClient with no options at all, discarding both the trust/key material (so TLS verified against the JVM default trust store instead of the configured cluster CA) and the configured limits (maxFrameSize/maxMessageSize fell back to 64 KiB/256 KiB instead of unlimited, and maxConnections to 50 instead of 8192, so oversized exec/attach messages were silently dropped even on plain HTTP). This affects kubernetes-httpclient-vertx-5 only, which is opt-in - the bundled default kubernetes-httpclient-vertx (Vert.x 4) serves WebSockets from the same client it reuses when deriving and was never affected - and it is present in 7.6.0 through 7.8.0. Derivation happens more often than it looks: OpenShiftClientImpl derives on every adapt(OpenShiftClient.class) to install its OAuth token-refresh interceptor, OpenShiftOAuthInterceptor derives on every token refresh, and BaseClient#newClient derives whenever a differing RequestConfig is set. Derived clients now reuse the original's WebSocketClient outright, the same way they already reused its HTTP client, so they can no longer drift from it and no second transport is allocated per derivation. Note that sharing the transport also means closing any client in a derived family closes it for the whole family: close() on a client obtained from adapt(OpenShiftClient.class) now ends WebSocket operations on the client it was derived from as well, which is already what happened to that client's HTTP requests and what the other four implementations do. Nothing usable is lost, since the original's HTTP client was closed regardless; what changes is that the per-derivation WebSocketClient is no longer left behind unclosed
  • Fix #8029: (httpclient-vertx-5, httpclient-jetty) WebSocket connections now honor the configured proxy, so exec/attach/portForward and WebSocket-backed watches no longer connect straight to the API server and bypass a mandated egress proxy. Both implementations serve WebSockets from a transport separate from the HTTP client (a Vert.x 5 WebSocketClient, and a second Jetty HttpClient behind the WebSocketClient) and neither was given the proxy configuration; Jetty's WebSocket transport now also receives the proxy BasicAuthentication entry. The OkHttp, JDK and Vert.x 4 modules were unaffected because a single client serves both. On httpclient-vertx-5 the configured connect timeout was not applied to the WebSocket client either, so a WebSocket connect could hang well past it. One consequence worth calling out: when the proxy credentials cannot be decoded - HttpClientUtils.decodeBasicCredentials returns null for anything that is not Basic, or whose decoded value does not split into exactly two :-separated parts, so a proxy password containing a colon is enough - the client falls back to stamping Proxy-Authorization on the request instead of configuring it on the transport. Such WebSocket connections now reach the proxy and are rejected with a 407 rather than silently completing straight to the API server, so a setup that appeared to work only because it was bypassing the proxy will now fail
  • Fix #7807: (kube-api-test) The KUBE_API_TEST_STARTUP_TIMEOUT environment variable is now parsed instead of throwing ClassCastException on every use — the value (always a String) was passed to Class.cast() for an Integer/Boolean target, which only widens reference types and never parses, so the timeout could not be configured via environment at all. A new startupTimeout attribute on @EnableKubeAPIServer (e.g. @EnableKubeAPIServer(startupTimeout = 180000)) allows overriding it declaratively, and all three configuration paths (annotation, builder, env var) now reject non-positive values
  • Fix #7983: (mockwebserver) WebSocket upgrades are now performed synchronously from the Vert.x request handler instead of from the asynchronous HttpServerRequest#body() callback. Deferring the upgrade let the request end event be processed first, so HttpServerRequest#toWebSocket() intermittently threw IllegalStateException: Request has already been read and the upgrade was lost (surfacing as flaky exec/attach mock-server tests). Upgrade requests carry no body, so they are detected via the Upgrade header and upgraded before the request is read; the asynchronous path is unchanged for regular HTTP requests
  • Fix #7955: (java-generator) Malicious CRD schema values can no longer inject executable code into the generated Java sources. Schema-controlled values (enum values, CRD group/version/names, property names, descriptions and defaults) are emitted as fully escaped Java string literals, so a value carrying a Unicode-escaped quote cannot break out of its literal once javac decodes it. As a defense in depth, each generated class is also re-parsed and structurally validated before it is written (with Java Unicode escape preprocessing enabled to match javac), aborting generation on any residual structural mismatch
  • Fix #8028: (openshift-model, kube-api-test) No package is shipped by two artifacts anymore, so each pair can be placed on the JPMS module path together. openshift-model no longer bundles the io.fabric8.openshift.api.model.config.* classes that openshift-model-config owns (its Export-Package wildcard inlined them from that dependency); they still reach consumers through it. Fabric8ClientInjectionHandler moved to io.fabric8.kubeapitest.junit.inject

Improvements

Dependency Upgrade

  • Fix #8033: bump gateway-api from 1.5.1 to 1.6.1

New Features

  • Fix #7752: Support for Kubernetes v1.37.0 (Garhwal)
  • Fix #8033: gateway-api model gains v1.TCPRoute and v1.UDPRoute (both graduated from v1alpha2 upstream in gateway-api v1.6.0). The v1alpha2 types remain available, but upstream has deprecated them and will remove them in a future release, so new code should use the v1 types

Note: Breaking changes

  • Fix #7752: Kubernetes model API removals (removed upstream in Kubernetes v1.37.0). The following API versions have been completely removed from Kubernetes and are no longer available in the client:
    • certificates.k8s.io/v1alpha1/ClusterTrustBundle → use certificates.k8s.io/v1 or v1beta1
    • networking.k8s.io/v1beta1/IPAddress → use networking.k8s.io/v1
    • networking.k8s.io/v1beta1/ServiceCIDR → use networking.k8s.io/v1
    • storage.k8s.io/v1beta1/VolumeAttributesClass → use storage.k8s.io/v1
    • scheduling.k8s.io/v1alpha2 (entire API version, 28 types) → use v1alpha3 or v1beta1
  • Fix #7752: VolumeMount constructor signature changed (Kubernetes v1.37.0 added bindMountOptions field). The canonical constructor now takes bindMountOptions (List) as its first parameter. Builder usage (new VolumeMountBuilder().with...()) is unaffected
  • Fix #8033: gateway-api model v1.SessionPersistence no longer exposes idleTimeout (removed upstream in gateway-api v1.6.0). Besides the field, this removes getIdleTimeout()/setIdleTimeout(), collapses the canonical constructor from five arguments to four, and drops SessionPersistenceFluent.withIdleTimeout()/getIdleTimeout()/hasIdleTimeout(), so the builder form (withNewSessionPersistence().withIdleTimeout(...)) no longer compiles. There is no runtime data loss: the class keeps its @JsonAnyGetter/@JsonAnySetter, and both the fluent and the builder carry additionalProperties through, so JSON or YAML still containing idleTimeout continues to deserialize and re-serialize intact
  • Fix #8028: (kube-api-test) Fabric8ClientInjectionHandler moved to io.fabric8.kubeapitest.junit.inject. It is resolved through ServiceLoader, so only code naming the class directly is affected
  • Fix #8028: (openshift-model) The bundle no longer exports or contains io.fabric8.openshift.api.model.config.*. Maven consumers are unaffected (openshift-model-config is a compile dependency), but OSGi deployments importing those packages must install the openshift-model-config bundle, which the openshift-client Karaf feature already does

New Contributors

Full Changelog: fabric8io/kubernetes-client@v7.8.0...v7.9.0

Changelog

Sourced from io.fabric8:kubernetes-httpclient-vertx's changelog.

7.9.0 (2026-09-04)

Bugs

  • Fix #8024: (httpclient-vertx-5) WebSocket operations (exec/attach/Description has been truncated

@dependabot
chore(deps): Bump kubernetes-client-version from 7.8.0 to 7.9.0
c42fea0 
Bumps `kubernetes-client-version` from 7.8.0 to 7.9.0.

Updates `io.fabric8:kubernetes-client` from 7.8.0 to 7.9.0
- [Release notes](https://github.com/fabric8io/kubernetes-client/releases)
- [Changelog](https://github.com/fabric8io/kubernetes-client/blob/main/CHANGELOG.md)
- [Commits](fabric8io/kubernetes-client@v7.8.0...v7.9.0)

Updates `io.fabric8:openshift-client` from 7.8.0 to 7.9.0
- [Release notes](https://github.com/fabric8io/kubernetes-client/releases)
- [Changelog](https://github.com/fabric8io/kubernetes-client/blob/main/CHANGELOG.md)
- [Commits](fabric8io/kubernetes-client@v7.8.0...v7.9.0)

Updates `io.fabric8:kubernetes-server-mock` from 7.8.0 to 7.9.0

Updates `io.fabric8:mockwebserver` from 7.8.0 to 7.9.0

Updates `io.fabric8:kubernetes-httpclient-vertx` from 7.8.0 to 7.9.0
- [Release notes](https://github.com/fabric8io/kubernetes-client/releases)
- [Changelog](https://github.com/fabric8io/kubernetes-client/blob/main/CHANGELOG.md)
- [Commits](fabric8io/kubernetes-client@v7.8.0...v7.9.0)

Updates `io.fabric8:openshift-model` from 7.8.0 to 7.9.0

Updates `io.fabric8:knative-model` from 7.8.0 to 7.9.0

---
updated-dependencies:
- dependency-name: io.fabric8:kubernetes-client
  dependency-version: 7.9.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
- dependency-name: io.fabric8:openshift-client
  dependency-version: 7.9.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
- dependency-name: io.fabric8:kubernetes-server-mock
  dependency-version: 7.9.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
- dependency-name: io.fabric8:mockwebserver
  dependency-version: 7.9.0
  dependency-type: direct:development
  update-type: version-update:semver-minor
- dependency-name: io.fabric8:kubernetes-httpclient-vertx
  dependency-version: 7.9.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
- dependency-name: io.fabric8:openshift-model
  dependency-version: 7.9.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
- dependency-name: io.fabric8:knative-model
  dependency-version: 7.9.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file java Pull requests that update Java code labels Sep 9, 2026
@github-actions

github-actions Bot commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

  • First-time contributors require MANUAL approval for the GitHub Actions to run
  • You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
  • You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
  • Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

@github-actions

github-actions Bot commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

🧪 CI tested the following changed modules:

  • parent

✅ POM dependency changes: targeted tests included

Changed properties: kubernetes-client-version

Modules affected by dependency changes (1)
  • :camel-kubernetes
🔬 Scalpel shadow comparison — Scalpel: 10 tested, 26 compile-only — current: 0 all tested

Maveniverse Scalpel detected 36 affected modules (current approach: 0).

⚠️ Modules only in Scalpel (36)
  • apache-camel
  • camel-allcomponents
  • camel-catalog
  • camel-catalog-console
  • camel-catalog-maven
  • camel-catalog-suggest
  • camel-componentdsl
  • camel-endpointdsl
  • camel-endpointdsl-support
  • camel-itest
  • camel-jbang-core
  • camel-jbang-it
  • camel-jbang-main
  • camel-jbang-mcp
  • camel-jbang-plugin-edit
  • camel-jbang-plugin-generate
  • camel-jbang-plugin-kubernetes
  • camel-jbang-plugin-mcp
  • camel-jbang-plugin-route-parser
  • camel-jbang-plugin-test
  • camel-jbang-plugin-tui
  • camel-jbang-plugin-validate
  • camel-kamelet-main
  • camel-kubernetes
  • camel-launcher
  • camel-launcher-container
  • camel-report-maven-plugin
  • camel-route-parser
  • camel-yaml-dsl
  • camel-yaml-dsl-deserializers
  • camel-yaml-dsl-maven-plugin
  • camel-yaml-dsl-validator
  • camel-yaml-dsl-validator-maven-plugin
  • coverage
  • docs
  • dummy-component

Changed properties: kubernetes-client-version

Skip-tests mode would test 10 modules (2 direct + 8 downstream), skip tests for 26 (generated code, meta-modules)

Modules Scalpel would test (10)
  • camel-jbang-mcp
  • camel-jbang-plugin-kubernetes
  • camel-jbang-plugin-mcp
  • camel-jbang-plugin-route-parser
  • camel-jbang-plugin-tui
  • camel-jbang-plugin-validate
  • camel-kubernetes
  • camel-launcher-container
  • camel-yaml-dsl-validator
  • camel-yaml-dsl-validator-maven-plugin
Modules with tests skipped (26)
  • apache-camel
  • camel-allcomponents
  • camel-catalog
  • camel-catalog-console
  • camel-catalog-maven
  • camel-catalog-suggest
  • camel-componentdsl
  • camel-endpointdsl
  • camel-endpointdsl-support
  • camel-itest
  • camel-jbang-core
  • camel-jbang-it
  • camel-jbang-main
  • camel-jbang-plugin-edit
  • camel-jbang-plugin-generate
  • camel-jbang-plugin-test
  • camel-kamelet-main
  • camel-launcher
  • camel-report-maven-plugin
  • camel-route-parser
  • camel-yaml-dsl
  • camel-yaml-dsl-deserializers
  • camel-yaml-dsl-maven-plugin
  • coverage
  • docs
  • dummy-component

ℹ️ Shadow mode — Scalpel observes but does not affect test execution. Learn more

All tested modules (37 modules, 2m 55s total)

Total reactor time: 2m 55s

Module Duration Status
Camel :: JBang :: Plugin :: TUI 25.3s FAILURE
Camel :: Component DSL 23.2s SUCCESS
Camel :: Catalog :: Camel Catalog 20.1s SUCCESS
Camel :: JBang :: Plugin :: Kubernetes 17.1s SUCCESS
Camel :: Docs 15.9s SUCCESS
Camel :: Kamelet Main 10.4s SUCCESS
Camel :: Catalog :: Camel Report Maven Plugin 10.1s SUCCESS
Camel :: JBang :: Plugin :: Testing 8.9s SUCCESS
Camel :: Catalog :: Camel Route Parser 8.2s SUCCESS
Camel :: YAML DSL :: Deserializers 7.2s SUCCESS
Camel :: YAML DSL :: Validator 5.7s SUCCESS
Camel :: All Components Sync point 5.2s SUCCESS
Camel :: YAML DSL :: Maven Plugins 3.0s SUCCESS
Camel :: Catalog :: Maven 3.0s SUCCESS
Camel :: Catalog :: Suggest 2.8s SUCCESS
Camel :: YAML DSL :: Validator Maven Plugin 2.3s SUCCESS
Camel :: Assembly 1.9s SUCCESS
Camel :: Parent 1.1s SUCCESS
Camel :: Catalog :: Dummy Component 1.0s SUCCESS
Camel :: JBang :: Plugin :: Validate 0.8s SUCCESS
Camel :: Endpoint DSL :: Support 0.7s SUCCESS
Camel :: JBang :: Plugin :: MCP 0.7s SUCCESS
Camel :: Catalog :: Console 0.6s SUCCESS
Camel :: Coverage n/a
Camel :: Endpoint DSL n/a
Camel :: Integration Tests n/a
Camel :: JBang :: Core n/a
Camel :: JBang :: Integration tests n/a
Camel :: JBang :: MCP n/a
Camel :: JBang :: Main n/a
Camel :: JBang :: Plugin :: Edit n/a
Camel :: JBang :: Plugin :: Generate n/a
Camel :: JBang :: Plugin :: Route Parser n/a
Camel :: Kubernetes n/a
Camel :: Launcher n/a
Camel :: Launcher :: Container n/a
Camel :: YAML DSL n/a

Top 20 slowest modules:

  • Camel :: JBang :: Plugin :: TUI (25.3s)
  • Camel :: Component DSL (23.2s)
  • Camel :: Catalog :: Camel Catalog (20.1s)
  • Camel :: JBang :: Plugin :: Kubernetes (17.1s)
  • Camel :: Docs (15.9s)
  • Camel :: Kamelet Main (10.4s)
  • Camel :: Catalog :: Camel Report Maven Plugin (10.1s)
  • Camel :: JBang :: Plugin :: Testing (8.9s)
  • Camel :: Catalog :: Camel Route Parser (8.2s)
  • Camel :: YAML DSL :: Deserializers (7.2s)
  • Camel :: YAML DSL :: Validator (5.7s)
  • Camel :: All Components Sync point (5.2s)
  • Camel :: YAML DSL :: Maven Plugins (3.0s)
  • Camel :: Catalog :: Maven (3.0s)
  • Camel :: Catalog :: Suggest (2.8s)
  • Camel :: YAML DSL :: Validator Maven Plugin (2.3s)
  • Camel :: Assembly (1.9s)
  • Camel :: Parent (1.1s)
  • Camel :: Catalog :: Dummy Component (1.0s)
  • Camel :: JBang :: Plugin :: Validate (0.8s)

⚙️ View full build and test results

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@davsclaus davsclaus davsclaus approved these changes

Assignees

No one assigned

Labels

core-build-and-dependencies dependencies Pull requests that update a dependency file java Pull requests that update Java code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@davsclaus