[camel-k] branch master updated: Fixed WARN in doc when generating website

[da...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

davsclaus pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/camel-k.git


The following commit(s) were added to refs/heads/master by this push:
     new 7977301  Fixed WARN in doc when generating website
7977301 is described below

commit 79773017133da8640da6963de6350cef3c12a296
Author: Claus Ibsen <cl...@gmail.com>
AuthorDate: Mon Mar 29 06:18:33 2021 +0200

    Fixed WARN in doc when generating website
---
 docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc b/docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
index 2ec9829..844ec08 100644
--- a/docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
+++ b/docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
@@ -115,7 +115,7 @@ spec:
 <2> Some endpoint parameters are just mapped 1-1
 <3> The Camel component `consumerKey` is named `apiKey` to reflect the actual name in the Twitter developer portal
 <4> The Camel Twitter component generates Java objects, so we marshal them to JSON
-<4> A Source Kamelet sends data to the special endpoint "kamelet:sink", that will be replaced at runtime by a different target
+<5> A Source Kamelet sends data to the special endpoint "kamelet:sink", that will be replaced at runtime by a different target
 
 The YAML route template above just uses the `twitter-search` component to do searches on Twitter. We added a marshalling step to JSON
 because the output of a Kamelet needs always to be something that can be transferred over the wire.
@@ -453,8 +453,8 @@ NOTE: We've truncated the list of "features" to just the first one, but it conta
 Since the integration above produces useful data, its route could be technically used to build a source Kamelet, but there are a few problems we may want to address before publishing it:
 
 1. It produces a lot of data (10762 events, last 30 days by default). We may want to start emitting events of the last e.g. 2 hours by default for this use case: we can add a filter on the query to accomplish this.
-1. It produces a collection of features (earthquake events), while you may want to push to the destination the individual features. We can use Camel's built-in `split` and `jsonpath` support to split the collection into separate entries.
-1. It continuously produces the same data: i.e. just wait another 10 seconds and you'll get the same data again and again (with a shift of 10 seconds over the last 30 days). A good approach here is to try to filter out duplicates at the source
+2. It produces a collection of features (earthquake events), while you may want to push to the destination the individual features. We can use Camel's built-in `split` and `jsonpath` support to split the collection into separate entries.
+3. It continuously produces the same data: i.e. just wait another 10 seconds and you'll get the same data again and again (with a shift of 10 seconds over the last 30 days). A good approach here is to try to filter out duplicates at the source
 as much as possible. We can think to store the time when the last update has been generated by the server and use it in subsequent queries to only obtain new events.
 This will not guarantee an "exactly once" semantics, because e.g. if the integration is restarted it will lose the in-memory state and start from the beginning,
 but it prevents sending an high amount of redundant data if the integration is kept alive.
@@ -759,7 +759,7 @@ spec:
 ----
 <1> The definition part starts with general information about the Kamelet
 <2> Definition of the "period" parameter (used with the `{{period}}` placeholder in the route)
-<2> Definition of the "lookAhead" parameter
+<3> Definition of the "lookAhead" parameter
 
 === Step 7: add metadata and sugar