chore: more replacements

addons/keda/keda_test.go

@@ -391,7 +391,7 @@ func TestHackKLBReplicas(t *testing.T) {
 	assert.NoError(t, keda.Apply(env))
 	scalesClient, err := env.Client.ScalesClient()
 	assert.NoError(t, err)
-	sc, err := scalesClient.Scales("test").Get(env.Ctx, camelv1.SchemeGroupVersion.WithResource("bindings").GroupResource(), "my-klb", metav1.GetOptions{})
+	sc, err := scalesClient.Scales("test").Get(env.Ctx, camelv1.SchemeGroupVersion.WithResource("pipes").GroupResource(), "my-klb", metav1.GetOptions{})
 	assert.NoError(t, err)
 	assert.Equal(t, int32(1), sc.Spec.Replicas)
 }

config/crd/kustomization.yaml

@@ -25,4 +25,4 @@ resources:
 - bases/camel.apache.org_integrations.yaml
 - bases/camel.apache.org_kamelets.yaml
 - bases/camel.apache.org_kameletbindings.yaml
-- bases/camel.apache.org_bindings.yaml
+- bases/camel.apache.org_pipes.yaml

config/manifests/bases/camel-k.clusterserviceversion.yaml

@@ -63,10 +63,10 @@ spec:
       kind: Integration
       name: integrations.camel.apache.org
       version: v1
-    - description: Binding is the Schema for the binding API
-      displayName: Binding
-      kind: Binding
-      name: bindings.camel.apache.org
+    - description: Pipe is the Schema for the pipes API
+      displayName: Pipe
+      kind: BindPipe
+      name: pipes.camel.apache.org
       version: v1alpha1
     - description: Kamelet is the Schema for the kamelets API
       displayName: Kamelet

config/rbac/openshift/operator-role-openshift.yaml

@@ -29,7 +29,8 @@ rules:
   - integrationkits/finalizers
   - integrationplatforms/finalizers
   - integrations/finalizers
-  - bindings/finalizers
+  - pipes/finalizers
+  - kameletbindings/finalizers
   verbs:
   - update
 - apiGroups:

config/rbac/operator-role.yaml

@@ -30,7 +30,7 @@ rules:
   - integrationkits
   - integrationplatforms
   - integrations
-  - bindings
+  - pipes
   # Deprecated: kameletbindings CR
   - kameletbindings
   - kamelets
@@ -56,8 +56,8 @@ rules:
   - integrationplatforms/status
   - integrations/scale
   - integrations/status
-  - bindings/status
-  - bindings/scale
+  - pipes/status
+  - pipes/scale
   # Deprecated: kameletbindings CR
   - kameletbindings/status
   - kameletbindings/scale

config/rbac/user-cluster-role.yaml

@@ -33,7 +33,7 @@ rules:
   - integrationkits
   - integrationplatforms
   - integrations
-  - bindings
+  - pipes
   # Deprecated: kameletbindings CR
   - kameletbindings
   - kamelets
@@ -55,8 +55,8 @@ rules:
   - integrationplatforms/status
   - integrations/scale
   - integrations/status
-  - bindings/scale
-  - bindings/status
+  - pipes/scale
+  - pipes/status
   # Deprecated: kameletbindings CR
   - kameletbindings/scale
   - kameletbindings/status

config/samples/kustomization.yaml

@@ -27,7 +27,8 @@ resources:
 - bases/camel_v1_camelcatalog.yaml
 - bases/camel_v1_build.yaml
 - bases/camel_v1_kamelet.yaml
-- bases/camel_v1_binding.yaml
+- bases/camel_v1_pipe.yaml
+- bases/camel_v1alpha1_kameletbinding.yaml
 
 patchesStrategicMerge:
 - patch-integration-platform.yaml

docs/modules/ROOT/nav.adoc

@@ -49,8 +49,8 @@
 *** xref:observability/monitoring/operator.adoc[Operator]
 *** xref:observability/monitoring/integration.adoc[Integration]
 * Scaling
-** xref:scaling/integration.adoc[Integration]
-** xref:scaling/binding.adoc[Binding]
+** xref:scaling/integration.adoc[Integrations]
+** xref:scaling/binding.adoc[Pipes]
 * xref:traits:traits.adoc[Traits]
 // Start of autogenerated code - DO NOT EDIT! (trait-nav)
 ** xref:traits:3scale.adoc[3Scale]

docs/modules/ROOT/pages/kamelets/kameletbindings-error-handler.adoc

@@ -1,12 +1,12 @@
 [[bindings-error-handler]]
-=Bindings Error Handler
+=Pipes Error Handler
 
-Bindings offer a mechanism to specify an error policy to adopt in case an event produced by a `source` or consumed by a `sink`. Through the definition of an `errorHandler` you will be able to apply certain logic to the failing event, such as simply logging, ignoring the event or posting the event to a `Sink`.
+Pipes offer a mechanism to specify an error policy to adopt in case an event produced by a `source` or consumed by a `sink`. Through the definition of an `errorHandler` you will be able to apply certain logic to the failing event, such as simply logging, ignoring the event or posting the event to a `Sink`.
 
 [source,yaml]
 ----
 apiVersion: camel.apache.org/v1alpha1
-kind: Binding
+kind: Pipe
 metadata:
   name: my-kamelet-binding
 spec:
@@ -33,7 +33,7 @@ There may be certain cases where you want to just ignore any failure happening o
 [source,yaml]
 ----
 apiVersion: camel.apache.org/v1alpha1
-kind: Binding
+kind: Pipe
 metadata:
   name: my-kamelet-binding
 spec:
@@ -54,7 +54,7 @@ Apache Camel offers a default behavior for handling any failure: log to standard
 [source,yaml]
 ----
 apiVersion: camel.apache.org/v1alpha1
-kind: Binding
+kind: Pipe
 metadata:
   name: my-kamelet-binding
 spec:
@@ -78,7 +78,7 @@ The `Sink` is probably the most interesting error handler type as it allows you
 [source,yaml]
 ----
 apiVersion: camel.apache.org/v1alpha1
-kind: Binding
+kind: Pipe
 metadata:
   name: my-kamelet-binding
 spec:

docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc

@@ -273,7 +273,7 @@ spec:
       - to: "kamelet:sink"
 ----
 <1> An icon with an appropriate license, better using svg+base64 URL encoding. You can encode icons using services like https://dopiaza.org/tools/datauri/index.php[this one]
-<2> The dataTypes section indicates that the Kamelet is going to produce JSON data as a default. The Kamelet is able to define multiple data types for in/out/error. The user will then be able to choose on of the data types in a Binding when referencing the Kamelet.
+<2> The dataTypes section indicates that the Kamelet is going to produce JSON data as a default. The Kamelet is able to define multiple data types for in/out/error. The user will then be able to choose on of the data types in a Pipe when referencing the Kamelet.
 <3> The previous YAML flow
 
 The Kamelet can be shared on the Catalog and or created on a Kubernetes cluster to let users use it.
@@ -294,7 +294,7 @@ Then you can create a binding like the following one to try it out:
 [source,yaml]
 ----
 apiVersion: camel.apache.org/v1alpha1
-kind: Binding
+kind: Pipe
 metadata:
   name: twitter-search-source-binding
 spec:
@@ -867,7 +867,7 @@ spec:
 ----
 <1> Add an icon with an appropriate license, better using svg+base64 URL encoding. You can encode icons using services like https://dopiaza.org/tools/datauri/index.php[this one]
 <2> This marks the Kamelet as dependant on Quarkus since we're specifying explicit dependencies on Quarkus artifacts in the `spec` -> `dependencies` section
-<3> The types section indicates that the Kamelet is going to produce JSON data by default. The Kamelet is able to define multiple data types for in/out/error. The user will then be able to choose on of the data types in a Binding when referencing the Kamelet.
+<3> The types section indicates that the Kamelet is going to produce JSON data by default. The Kamelet is able to define multiple data types for in/out/error. The user will then be able to choose on of the data types in a Pipe when referencing the Kamelet.
 <4> Dependencies that we previously specified in the modeline options should be expressed now in the Kamelet spec
 
 The Kamelet is now ready to be used!
@@ -893,7 +893,7 @@ To check if it works, you can create a simple binding:
 [source,yaml]
 ----
 apiVersion: camel.apache.org/v1alpha1
-kind: Binding
+kind: Pipe
 metadata:
   name: earthquake-source-binding
 spec:
@@ -1217,7 +1217,7 @@ So, for example, to send a text message to a chat, we may create a binding like
 [source,yaml]
 ----
 apiVersion: camel.apache.org/v1alpha1
-kind: Binding
+kind: Pipe
 metadata:
   name: telegram-text-binding
 spec:
@@ -1261,7 +1261,7 @@ To check if we can also receive pictures using the above Kamelet, we can create
 [source,yaml]
 ----
 apiVersion: camel.apache.org/v1alpha1
-kind: Binding
+kind: Pipe
 metadata:
   name: telegram-image-binding
 spec:
@@ -1314,16 +1314,16 @@ Feature: Kamelet earthquake-source works
   Scenario: Bind Kamelet to service
     Given create Kubernetes service test-service with target port 8080
     And bind Kamelet earthquake-source to uri http://test-service.${YAKS_NAMESPACE}.svc.cluster.local/test
-    When create Binding earthquake-source-uri
-    Then Binding earthquake-source-uri should be available
+    When create Pipe earthquake-source-uri
+    Then Pipe earthquake-source-uri should be available
     And Camel K integration earthquake-source-uri should be running
 
   Scenario: Verify binding
     Given HTTP server "test-service"
     And HTTP server timeout is 120000 ms
     Then expect HTTP request header: Content-Type="application/json;charset=UTF-8"
     And receive POST /test
-    And delete Binding earthquake-source-uri
+    And delete Pipe earthquake-source-uri
 ----
 
 As you see this is a declarative test that is materialized into something that actually checks that the service generates some data.
@@ -1356,7 +1356,7 @@ send data to it via HTTP. Let's create a parameterized binding like the followin
 [source,yaml]
 ----
 apiVersion: camel.apache.org/v1alpha1
-kind: Binding
+kind: Pipe
 metadata:
   name: webhook-to-telegram
 spec:
@@ -1406,8 +1406,8 @@ Feature: Kamelet telegram-sink works
 
   Scenario: Bind webhook to Kamelet sink
     Given load variables telegram-credentials.properties
-    And load Binding webhook-to-telegram.yaml
-    Then Binding webhook-to-telegram should be available
+    And load Pipe webhook-to-telegram.yaml
+    Then Pipe webhook-to-telegram should be available
     And Camel K integration webhook-to-telegram should be running
 
 
@@ -1423,7 +1423,7 @@ Feature: Kamelet telegram-sink works
     """
     When send POST /message
     Then receive HTTP 200 OK
-    And delete Binding webhook-to-telegram
+    And delete Pipe webhook-to-telegram
 
 ----
 

docs/modules/ROOT/pages/kamelets/kamelets-user.adoc

@@ -278,19 +278,19 @@ In some contexts (for example **"serverless"**) users often want to leverage the
 doing additional processing (such as tranformations or other enterprise integration patterns).
 
 A common use case is that of **Knative Sources**, for which the Apache Camel developers maintain the https://knative.dev/docs/eventing/samples/apache-camel-source/[Knative CamelSources].
-Kamelets represent an **evolution** of the model proposed in CamelSources, but they allow using the same declarative style of binding, via a resource named **Binding**.
+Kamelets represent an **evolution** of the model proposed in CamelSources, but they allow using the same declarative style of binding, via a resource named **Pipe**.
 
 === Binding to a Knative Destination
 
-A Binding allows to declaratively move data from a system described by a Kamelet towards a Knative destination (or other kind of destinations, in the future), or from
+A Pipe allows to declaratively move data from a system described by a Kamelet towards a Knative destination (or other kind of destinations, in the future), or from
 a Knative channel/broker to another external system described by a Kamelet.
 
 For example, here's an example of binding:
 
 [source,yaml]
 ----
 apiVersion: camel.apache.org/v1alpha1
-kind: Binding
+kind: Pipe
 metadata:
   name: telegram-text-source-to-channel
 spec:
@@ -315,11 +315,11 @@ makes sure that messages produced by the Kamelet are forwarded to the Knative **
 
 Note that source and sink are specified declaratively as standard **Kubernetes object references**.
 
-The example shows how we can reference the "telegram-text-source" resource in a Binding. It's contained in the `source` section
+The example shows how we can reference the "telegram-text-source" resource in a Pipe. It's contained in the `source` section
 because it's a Kamelet of type "source".
-A Kamelet of type "sink", by contrast, can only be used in the `sink` section of a `Binding`.
+A Kamelet of type "sink", by contrast, can only be used in the `sink` section of a `Pipe`.
 
-**Under the covers, a Binding creates an Integration** resource that implements the binding, but this is transparent to the end user.
+**Under the covers, a Pipe creates an Integration** resource that implements the binding, but this is transparent to the end user.
 
 === Binding to a Kafka Topic
 
@@ -338,7 +338,7 @@ The following binding can be created to push data into the `my-topic` topic:
 [source,yaml]
 ----
 apiVersion: camel.apache.org/v1alpha1
-kind: Binding
+kind: Pipe
 metadata:
   name: telegram-text-source-to-kafka
 spec:
@@ -361,13 +361,13 @@ After creating it, messages will flow from Telegram to Kafka.
 
 === Binding to an explicit URI
 
-An alternative way to use a Binding is to configure the source/sink to be an explicit Camel URI.
+An alternative way to use a Pipe is to configure the source/sink to be an explicit Camel URI.
 For example, the following binding is allowed:
 
 [source,yaml]
 ----
 apiVersion: camel.apache.org/v1alpha1
-kind: Binding
+kind: Pipe
 metadata:
   name: telegram-text-source-to-channel
 spec:
@@ -381,25 +381,25 @@ spec:
   sink:
     uri: https://mycompany.com/the-service # <1>
 ----
-<1> Binding with explicitly URI
+<1> Pipe with explicitly URI
 
-This Binding explicitly defines an URI where data is going to be pushed.
+This Pipe explicitly defines an URI where data is going to be pushed.
 
 NOTE: the `uri` option is also conventionally used in Knative to specify a non-kubernetes destination.
 To comply with the Knative specifications, in case an "http" or "https" URI is used, Camel will send https://cloudevents.io/[CloudEvents] to the destination.
 
 === Error Handling
 
-You can configure an error handler in order to specify what to do when some event ends up with failure. See xref:kamelets/bindings-error-handler.adoc[Bindings Error Handler User Guide] for more detail.
+You can configure an error handler in order to specify what to do when some event ends up with failure. See xref:kamelets/bindings-error-handler.adoc[Pipes Error Handler User Guide] for more detail.
 
 === Trait via annotations
 
-You can easily tune your `Binding` with xref:traits:traits.adoc[traits] configuration adding `.metadata.annotations`. Let's have a look at the following example:
+You can easily tune your `Pipe` with xref:traits:traits.adoc[traits] configuration adding `.metadata.annotations`. Let's have a look at the following example:
 
 [source,yaml]
 ----
 apiVersion: camel.apache.org/v1alpha1
-kind: Binding
+kind: Pipe
 metadata:
   name: timer-2-log-annotation
   annotations: # <1>
@@ -578,7 +578,7 @@ Data shapes contain the following information:
 |E.g. `aws2-s3`
 
 |`format`
-|The data shape name used to identify and reference the data type in a Binding when choosing from multiple data type options.
+|The data shape name used to identify and reference the data type in a Pipe when choosing from multiple data type options.
 |`string`
 |E.g. `json`
 
@@ -653,13 +653,13 @@ which is set to the name of a specific KEDA autoscaler.
 A KEDA enabled Kamelet can be used in the same way as any other Kamelet, in a binding or in an integration.
 KEDA autoscalers are not enabled by default: they need to be manually enabled by the user via the `keda` trait.
 
-In a Binding, the KEDA trait can be enabled using annotations:
+In a Pipe, the KEDA trait can be enabled using annotations:
 
 .my-keda-binding.yaml
 [source,yaml]
 ----
 apiVersion: camel.apache.org/v1alpha1
-kind: Binding
+kind: Pipe
 metadata:
   name: my-keda-binding
   annotations:

docs/modules/ROOT/pages/kamelets/kamelets.adoc

@@ -4,5 +4,5 @@
 This section of the documentation contains information about Kamelets from both a user and a developer point of view:
 
 - The xref:kamelets/kamelets-user.adoc[Kamelets User Guide] is for users that want to use Kamelets for connecting systems with their applications
-- The xref:kamelets/bindings-error-handler.adoc[Bindings Error Handler User Guide] explains how to configure an error handler on a `Binding`
+- The xref:kamelets/bindings-error-handler.adoc[Pipes Error Handler User Guide] explains how to configure an error handler on a `Pipe`
 - The xref:kamelets/kamelets-dev.adoc[Kamelets Developer Guide] is a reference for developers that want to create new Kamelets and share them with users

docs/modules/ROOT/pages/running/knative-sink.adoc

@@ -10,12 +10,12 @@ from('timer:tick')
   .to('knative:event/broker')
 ----
 
-Or as the value of the `sink` field in a `Binding` resource, e.g.:
+Or as the value of the `sink` field in a `Pipe` resource, e.g.:
 
 [source,yaml]
 ----
 apiVersion: camel.apache.org/v1alpha1
-kind: Binding
+kind: Pipe
 metadata:
   name: timer-source-binding
 spec: