apache/camel-k

Bug description --- FAIL: TestRunAndLogErrorMvn (2.89s) maven_log_test.go:41: Error Trace: /home/runner/work/camel-k/camel-k/pkg/util/maven/maven_log_test.go:41 Error: Error "BUILD FAILURE: exit status 1" does not contain "The goal you specified requires a project to execute but there is no POM in this directory" Test: TestRunAndLogErrorMvn Likely the new runner image produce a different error that we need to track better. Camel K or runtime version No response

When a Camel K Integration exposes a Kubernetes Service, Camel K should also create a corresponding Kubernetes NetworkPolicy to control access to the Integration. The NetworkPolicy should be managed by the existing Service trait, keeping the Service exposure and its network access policy together. By default, the NetworkPolicy should be enabled whenever the Service trait is enabled. Users should be able to disable the NetworkPolicy and configure which namespaces and pods are allowed to access the Integration. Motivation Exposing an Integration through a Kubernetes Service makes the Integration reachable through the Kubernetes network. In environments where network access is restricted using NetworkPolicy, users should not have to manually create an additional resource to secure the Service. The Service trait already owns the configuration and lifecycle of the Service exposed by an Integration, so it is a natural place to manage the associated NetworkPolicy as well. This would allow a S

--- FAIL: TestGenerateKeystore (2.44s) keystore_test.go:45: Error Trace: /.../pkg/util/jvm/keystore_test.go:45 Error: Not equal: expected: "keytool error: java.io.IOException: keystore password was incorrect: exit status 1" actual : "keytool error: java.lang.Exception: Input not an X.509 certificate: exit status 1" The output error could be different according the JDK used. We should instead assert just the first part of the error string.

For Kafka binding, we are using a new client: type StrimziBindingProvider struct { Client internalclientset.Interface } We should instead make use of the one provided normally in the BindingContext which is available in the Translate func.

Requirement Continue the work started in #5935 and add a Pipe binding for ArkMQ operator based queues. Ideally we need to make a similar approach of what we have for Strimzi/Kafka: Verify how to install the ArkMQ operator and how to create a simple queue Use this procedure to create a new workflow to be eventually used for e2e Develop a duck type for the custom resource that represents a queue Develop the business logic to transform a Pipe binding (eg, timer to queue) to a Camel route with proper configuration Provide the mapping and the support for the main parameters expected from the queue: let's start with the basic ones to connect and secure the connection, avoid starting with a complete definition. Also, only provide those expected by the custom resource Develop proper unit test Develop an e2e test that covers pushing to a queue (timer to queue) and polling from the queue (queue to log) Use Kafka as a reference as it is very similar approach for all the steps.