Fixed WARN in doc when generating website
@@ -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
