This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new 4e9d586b94f CAMEL-20410: documentation fixes for base files
4e9d586b94f is described below
commit 4e9d586b94fc3fb685f7be1b9ac43c32238f2ff3
Author: Otavio R. Piske <[email protected]>
AuthorDate: Sun Feb 18 12:25:16 2024 +0100
CAMEL-20410: documentation fixes for base files
- Fixed grammar and typos
- Fixed punctuation
- Added and/or fixed links
Signed-off-by: Otavio R. Piske <[email protected]>
---
.../ROOT/partials/component-configure-options.adoc | 38 +++++++++++++---------
.../ROOT/partials/component-endpoint-options.adoc | 12 +++----
2 files changed, 29 insertions(+), 21 deletions(-)
diff --git
a/docs/components/modules/ROOT/partials/component-configure-options.adoc
b/docs/components/modules/ROOT/partials/component-configure-options.adoc
index a58fbb4864e..11ce420e2c6 100644
--- a/docs/components/modules/ROOT/partials/component-configure-options.adoc
+++ b/docs/components/modules/ROOT/partials/component-configure-options.adoc
@@ -8,28 +8,36 @@ Camel components are configured on two separate levels:
=== Configuring Component Options
-The component level is the highest level which holds general and common
configurations that are inherited by the endpoints.
-For example a component may have security settings, credentials for
authentication, urls for network connection and so forth.
+At the component level, you set general and shared configurations that are,
then, inherited by the endpoints. It is the highest configuration level.
-Some components only have a few options, and others may have many. Because
components typically have pre configured defaults
-that are commonly used, then you may often only need to configure a few
options on a component; or none at all.
+For example, a component may have security settings, credentials for
authentication, urls for network connection and so forth.
-Configuring components can be done with the
xref:manual::component-dsl.adoc[Component DSL],
-in a configuration file (application.properties|yaml), or directly with Java
code.
+Some components only have a few options, and others may have many.
+Because components typically have pre-configured defaults that are commonly
used, then you may often only need to configure a few options on a component;
or none at all.
+
+You can configure components using:
+
+* the xref:manual::component-dsl.adoc[Component DSL].
+* in a configuration file (`application.properties`, `*.yaml` files, etc).
+* directly in the Java code.
=== Configuring Endpoint Options
-Where you find yourself configuring the most is on endpoints, as endpoints
often have many options, which allows you to
-configure what you need the endpoint to do. The options are also categorized
into whether the endpoint is used as consumer (from)
-or as a producer (to), or used for both.
+You usually spend more time setting up endpoints because they have many
options.
+These options help you customize what you want the endpoint to do.
+The options are also categorized into whether the endpoint is used as a
consumer (_from_), as a producer (_to_), or both.
-Configuring endpoints is most often done directly in the endpoint URI as path
and query parameters. You can also use
-the xref:manual::Endpoint-dsl.adoc[Endpoint DSL] and
xref:manual::dataformat-dsl.adoc[DataFormat DSL]
+Configuring endpoints is most often done directly in the endpoint URI as
_path_ and _query_ parameters.
+You can also use the xref:manual::Endpoint-dsl.adoc[Endpoint DSL] and
xref:manual::dataformat-dsl.adoc[DataFormat DSL]
as a _type safe_ way of configuring endpoints and data formats in Java.
-A good practice when configuring options is to use
xref:manual::using-propertyplaceholder.adoc[Property Placeholders],
-which allows to not hardcode urls, port numbers, sensitive information, and
other settings.
-In other words placeholders allows to externalize the configuration from your
code, and gives more flexibility and reuse.
+A good practice when configuring options is to use
xref:manual::using-propertyplaceholder.adoc[Property Placeholders].
+
+Property placeholders provide a few benefits:
+
+* They help prevent using hardcoded urls, port numbers, sensitive information,
and other settings.
+* They allow externalizing the configuration from the code.
+* They help the code to become more flexible and reusable.
-The following two sections lists all the options, firstly for the component
followed by the endpoint.
+The following two sections list all the options, firstly for the component
followed by the endpoint.
// component-configure options: END
diff --git
a/docs/components/modules/ROOT/partials/component-endpoint-options.adoc
b/docs/components/modules/ROOT/partials/component-endpoint-options.adoc
index c69eb1eec4b..623fb3f3830 100644
--- a/docs/components/modules/ROOT/partials/component-endpoint-options.adoc
+++ b/docs/components/modules/ROOT/partials/component-endpoint-options.adoc
@@ -32,7 +32,7 @@ The {doctitle} endpoint is configured using URI syntax:
{syntax}
----
-with the following path and query parameters:
+With the following _path_ and _query_ parameters:
=== Path Parameters ({pathparametercount} parameters)
@@ -54,7 +54,7 @@ endif::[]
=== Query Parameters ({queryparametercount} parameters)
ifeval::[{queryparametercount} == 0]
-The {doctitle} endpoint has no query parameters.
+The {doctitle} endpoint has no _query_ parameters.
endif::[]
ifeval::[{queryparametercount} != 0]
@@ -70,7 +70,7 @@ ifeval::[{apicount} != 0]
== API Parameters ({apicount} APIs)
-The {doctitle} endpoint is an API based component and has additional
parameters based on which API name and API method is used.
+The {doctitle} endpoint is an API-based component and has additional
parameters based on which API name and API method is used.
The API name and API method is located in the endpoint URI as the
`{apiSyntax}` path parameters:
[subs='+attributes']
@@ -110,8 +110,8 @@ The {apiname} API is defined in the syntax as follows:
{scheme}:{apiname}/methodName?[parameters]
------
-The {methodcount} method(s) is listed in the table below, followed by detailed
syntax for each method.
-(API methods can have a shorthand alias name which can be used in the syntax
instead of the name)
+The {methodcount} method(s) is(are) listed in the table below, followed by
detailed syntax for each method.
+(API methods can have a shorthand _alias_ name which can be used in the syntax
instead of the name)
[width="100%",cols="2,2,6a",options="header"]
|===
@@ -144,7 +144,7 @@ In addition to the parameters above, the {name} API can
also use any of the <<#_
Any of the parameters can be provided in either the endpoint URI, or
dynamically in a message header.
The message header name must be of the format
`Camel{pascalcasescheme}.parameter`.
-The `inBody` parameter overrides message header, i.e. the endpoint parameter
`inBody=myParameterNameHere`
+The `inBody` parameter overrides message header, i.e., the endpoint parameter
`inBody=myParameterNameHere`
would override a `Camel{pascalcasescheme}.myParameterNameHere` header.
%endif::[]
