Polish documentation title case

philwebb · philwebb · commit c416c17fe855 · 2022-10-19T21:53:21.000-07:00
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/actuator/endpoints.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/actuator/endpoints.adoc
@@ -1034,7 +1034,7 @@ This would make `liveness` available at `/livez` and `readiness` at `readyz` on
 
 
 [[actuator.endpoints.kubernetes-probes.external-state]]
-==== Checking External State with Kubernetes Probes
+==== Checking External State With Kubernetes Probes
 Actuator configures the "`liveness`" and "`readiness`" probes as Health Groups.
 This means that all the <<actuator#actuator.endpoints.health.groups, health groups features>> are available for them.
 You can, for example, configure additional Health Indicators:
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/actuator/monitoring.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/actuator/monitoring.adoc
@@ -1,5 +1,5 @@
 [[actuator.monitoring]]
-== Monitoring and Management over HTTP
+== Monitoring and Management Over HTTP
 If you are developing a web application, Spring Boot Actuator auto-configures all enabled endpoints to be exposed over HTTP.
 The default convention is to use the `id` of the endpoint with a prefix of `/actuator` as the URL path.
 For example, `health` is exposed as `/actuator/health`.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/cli/groovy-beans-dsl.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/cli/groovy-beans-dsl.adoc
@@ -1,5 +1,5 @@
 [[cli.groovy-beans-dsl]]
-== Developing Applications with the Groovy Beans DSL
+== Developing Applications With the Groovy Beans DSL
 Spring Framework 4.0 has native support for a `beans{}` "`DSL`" (borrowed from https://grails.org/[Grails]), and you can embed bean definitions in your Groovy application scripts by using the same format.
 This is sometimes a good way to include external features like middleware declarations, as shown in the following example:
 
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/cli/maven-setting.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/cli/maven-setting.adoc
@@ -1,5 +1,5 @@
 [[cli.maven-setting]]
-== Configuring the CLI with settings.xml
+== Configuring the CLI With settings.xml
 The Spring Boot CLI uses Maven Resolver, Maven's dependency resolution engine, to resolve dependencies.
 The CLI makes use of the Maven configuration found in `~/.m2/settings.xml` to configure Maven Resolver.
 The following configuration settings are honored by the CLI:
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/cli/using-the-cli.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/cli/using-the-cli.adoc
@@ -50,7 +50,7 @@ The `version` command provides a quick way to check which version of Spring Boot
 
 
 [[cli.using-the-cli.run]]
-=== Running Applications with the CLI
+=== Running Applications With the CLI
 You can compile and run Groovy source code by using the `run` command.
 The Spring Boot CLI is completely self-contained, so you do not need any external Groovy installation.
 
@@ -197,7 +197,7 @@ However, to ensure consistent ordering of the dependency management, you can use
 
 
 [[cli.using-the-cli.multiple-source-files]]
-=== Applications with Multiple Source Files
+=== Applications With Multiple Source Files
 You can use "`shell globbing`" with all commands that accept file input.
 Doing so lets you use multiple files from a single directory, as shown in the following example:
 
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/container-images/efficient-images.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/container-images/efficient-images.adoc
@@ -1,5 +1,5 @@
 [[container-images.efficient-images]]
-== Efficient container images
+== Efficient Container Images
 It is easily possible to package a Spring Boot fat jar as a docker image.
 However, there are various downsides to copying and running the fat jar as is in the docker image.
 There’s always a certain amount of overhead when running a fat jar without unpacking it, and in a containerized environment this can be noticeable.
@@ -9,7 +9,7 @@ If you put jar files in the layer before your application classes, Docker often
 
 
 [[container-images.efficient-images.unpacking]]
-=== Unpacking the fat jar
+=== Unpacking the Executable JAR
 If you are running your application from a container, you can use an executable jar, but it is also often an advantage to explode it and run it in a different way.
 Certain PaaS implementations may also choose to unpack archives before they run.
 For example, Cloud Foundry operates this way.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/data/nosql.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/data/nosql.adoc
@@ -275,7 +275,7 @@ Spring Boot provides a dedicated "`Starter`", `spring-boot-starter-data-elastics
 
 
 [[data.nosql.elasticsearch.connecting-using-rest]]
-==== Connecting to Elasticsearch using REST clients
+==== Connecting to Elasticsearch Using REST clients
 Elasticsearch ships https://www.elastic.co/guide/en/elasticsearch/client/java-rest/current/index.html[two different REST clients] that you can use to query a cluster: the "Low Level" client and the "High Level" client.
 Spring Boot provides support for the "High Level" client, which ships with `org.elasticsearch.client:elasticsearch-rest-high-level-client`.
 Additionally, Spring Boot provides support for a reactive client, based on Spring Framework's `WebClient`, that ships with `org.springframework.data:spring-data-elasticsearch`.
@@ -293,7 +293,7 @@ You can use `spring.elasticsearch.*` properties to further tune how the clients
 ----
 
 [[data.nosql.elasticsearch.connecting-using-rest.restclient]]
-===== Connecting to Elasticsearch using RestHighLevelClient
+===== Connecting to Elasticsearch Using RestHighLevelClient
 If you have `elasticsearch-rest-high-level-client` on the classpath, Spring Boot will auto-configure and register a `RestHighLevelClient` bean.
 In addition to the properties described previously, to fine-tune the `RestHighLevelClient`, you can register an arbitrary number of beans that implement `RestClientBuilderCustomizer` for more advanced customizations.
 To take full control over its registration, define a `RestClientBuilder` bean.
@@ -316,7 +316,7 @@ You can further tune how `Sniffer` is configured, as shown in the following exam
 
 
 [[data.nosql.elasticsearch.connecting-using-rest.webclient]]
-===== Connecting to Elasticsearch using ReactiveElasticsearchClient
+===== Connecting to Elasticsearch Using ReactiveElasticsearchClient
 {spring-data-elasticsearch}[Spring Data Elasticsearch] ships `ReactiveElasticsearchClient` for querying Elasticsearch instances in a reactive fashion.
 It is built on top of WebFlux's `WebClient`, so both `spring-boot-starter-elasticsearch` and `spring-boot-starter-webflux` dependencies are useful to enable this support.
 
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/documentation/using.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/documentation/using.adoc
@@ -1,5 +1,5 @@
 [[documentation.using]]
-== Developing with Spring Boot
+== Developing With Spring Boot
 Ready to actually start using Spring Boot? <<using#using, We have you covered>>:
 
 * *Build systems:* <<using#using.build-systems.maven, Maven>> | <<using#using.build-systems.gradle, Gradle>> | <<using#using.build-systems.ant, Ant>> | <<using#using.build-systems.starters, Starters>>
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/executable-jar/jarfile-class.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/executable-jar/jarfile-class.adoc
@@ -26,7 +26,7 @@ We do not need to unpack the archive, and we do not need to read all entry data
 
 
 [[appendix.executable-jar.jarfile-class.compatibility]]
-=== Compatibility with the Standard Java "`JarFile`"
+=== Compatibility With the Standard Java "`JarFile`"
 Spring Boot Loader strives to remain compatible with existing code and libraries.
 `org.springframework.boot.loader.jar.JarFile` extends from `java.util.jar.JarFile` and should work as a drop-in replacement.
 The `getURL()` method returns a `URL` that opens a connection compatible with `java.net.JarURLConnection` and can be used with Java's `URLClassLoader`.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/features/external-config.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/features/external-config.adoc
@@ -101,7 +101,7 @@ This means that the JSON cannot override properties from lower order property so
 
 
 [[features.external-config.files]]
-=== External Application Properties [[features.external-config.files]]
+=== External Application Properties
 Spring Boot will automatically find and load `application.properties` and `application.yaml` files from the following locations when your application starts:
 
 . From the classpath
@@ -474,7 +474,7 @@ See the _<<howto#howto.properties-and-configuration.short-command-line-arguments
 
 
 [[features.external-config.files.multi-document]]
-==== Working with Multi-Document Files
+==== Working With Multi-Document Files
 Spring Boot allows you to split a single physical file into multiple logical documents which are each added independently.
 Documents are processed in order, from top to bottom.
 Later documents can override the properties defined in earlier ones.
@@ -567,7 +567,7 @@ If you need a secure way to store credentials and passwords, the https://cloud.s
 
 
 [[features.external-config.yaml]]
-=== Working with YAML
+=== Working With YAML
 https://yaml.org[YAML] is a superset of JSON and, as such, is a convenient format for specifying hierarchical configuration data.
 The `SpringApplication` class automatically supports YAML as an alternative to properties whenever you have the https://github.com/snakeyaml/snakeyaml[SnakeYAML] library on your classpath.
 
@@ -680,7 +680,7 @@ TIP: See also the <<features#features.external-config.typesafe-configuration-pro
 
 
 [[features.external-config.typesafe-configuration-properties.java-bean-binding]]
-==== JavaBean properties binding
+==== JavaBean Properties Binding
 It is possible to bind a bean declaring standard JavaBean properties as shown in the following example:
 
 [source,java,indent=0,subs="verbatim"]
@@ -721,7 +721,7 @@ Finally, only standard Java Bean properties are considered and binding on static
 
 
 [[features.external-config.typesafe-configuration-properties.constructor-binding]]
-==== Constructor binding
+==== Constructor Binding
 The example in the previous section can be rewritten in an immutable fashion as shown in the following example:
 
 [source,java,indent=0,subs="verbatim"]
@@ -760,7 +760,7 @@ For consistency with properties of other types, if you do declare an `Optional`
 
 
 [[features.external-config.typesafe-configuration-properties.enabling-annotated-types]]
-==== Enabling @ConfigurationProperties-annotated types
+==== Enabling @ConfigurationProperties-annotated Types
 Spring Boot provides infrastructure to bind `@ConfigurationProperties` types and register them as beans.
 You can either enable configuration properties on a class-by-class basis or enable configuration property scanning that works in a similar manner to component scanning.
 
@@ -798,7 +798,7 @@ If you still want to inject other beans using the constructor, the configuration
 
 
 [[features.external-config.typesafe-configuration-properties.using-annotated-types]]
-==== Using @ConfigurationProperties-annotated types
+==== Using @ConfigurationProperties-annotated Types
 This style of configuration works particularly well with the `SpringApplication` external YAML configuration, as shown in the following example:
 
 [source,yaml,indent=0,subs="verbatim"]
@@ -941,7 +941,7 @@ For example, binding `a.b=c` to `Map<String, Object>` will return a Map with the
 
 
 [[features.external-config.typesafe-configuration-properties.relaxed-binding.environment-variables]]
-===== Binding from Environment Variables
+===== Binding From Environment Variables
 Most operating systems impose strict rules around the names that can be used for environment variables.
 For example, Linux shell variables can contain only letters (`a` to `z` or `A` to `Z`), numbers (`0` to `9`) or the underscore character (`_`).
 By convention, Unix shell variables will also have their names in UPPERCASE.
@@ -1117,7 +1117,7 @@ Doing so gives a transparent upgrade path while supporting a much richer format.
 
 
 [[features.external-config.typesafe-configuration-properties.conversion.periods]]
-===== Converting periods
+===== Converting Periods
 In addition to durations, Spring Boot can also work with `java.time.Period` type.
 The following formats can be used in application properties:
 
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/features/kotlin.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/features/kotlin.adoc
@@ -1,5 +1,5 @@
 [[features.kotlin]]
-== Kotlin support
+== Kotlin Support
 https://kotlinlang.org[Kotlin] is a statically-typed language targeting the JVM (and other platforms) which allows writing concise and elegant code while providing {kotlin-docs}java-interop.html[interoperability] with existing libraries written in Java.
 
 Spring Boot provides Kotlin support by leveraging the support in other Spring projects such as Spring Framework, Spring Data, and Reactor.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/features/testing.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/features/testing.adoc
@@ -171,7 +171,7 @@ include::{docs-java}/features/testing/springbootapplications/usingapplicationarg
 
 
 [[features.testing.spring-boot-applications.with-mock-environment]]
-==== Testing with a mock environment
+==== Testing With a Mock Environment
 By default, `@SpringBootTest` does not start the server but instead sets up a mock environment for testing web endpoints.
 
 With Spring MVC, we can query our web endpoints using {spring-framework-docs}/testing.html#spring-mvc-test-framework[`MockMvc`] or `WebTestClient`, as shown in the following example:
@@ -203,7 +203,7 @@ If you need to test these lower-level concerns, you can start a fully running se
 
 
 [[features.testing.spring-boot-applications.with-running-server]]
-==== Testing with a running server
+==== Testing With a Running Server
 If you need to start a full running server, we recommend that you use random ports.
 If you use `@SpringBootTest(webEnvironment=WebEnvironment.RANDOM_PORT)`, an available port is picked at random each time your test runs.
 
@@ -710,7 +710,7 @@ It can also be used to configure the host, scheme, and port that appears in any
 
 
 [[features.testing.spring-boot-applications.autoconfigured-spring-restdocs.with-mock-mvc]]
-===== Auto-configured Spring REST Docs Tests with Mock MVC
+===== Auto-configured Spring REST Docs Tests With Mock MVC
 `@AutoConfigureRestDocs` customizes the `MockMvc` bean to use Spring REST Docs when testing servlet-based web applications.
 You can inject it by using `@Autowired` and use it in your tests as you normally would when using Mock MVC and Spring REST Docs, as shown in the following example:
 
@@ -738,7 +738,7 @@ include::{docs-java}/features/testing/springbootapplications/autoconfiguredsprin
 
 
 [[features.testing.spring-boot-applications.autoconfigured-spring-restdocs.with-web-test-client]]
-===== Auto-configured Spring REST Docs Tests with WebTestClient
+===== Auto-configured Spring REST Docs Tests With WebTestClient
 `@AutoConfigureRestDocs` can also be used with `WebTestClient` when testing reactive web applications.
 You can inject it by using `@Autowired` and use it in your tests as you normally would when using `@WebFluxTest` and Spring REST Docs, as shown in the following example:
 
@@ -765,7 +765,7 @@ include::{docs-java}/features/testing/springbootapplications/autoconfiguredsprin
 
 
 [[features.testing.spring-boot-applications.autoconfigured-spring-restdocs.with-rest-assured]]
-===== Auto-configured Spring REST Docs Tests with REST Assured
+===== Auto-configured Spring REST Docs Tests With REST Assured
 `@AutoConfigureRestDocs` makes a `RequestSpecification` bean, preconfigured to use Spring REST Docs, available to your tests.
 You can inject it by using `@Autowired` and use it in your tests as you normally would when using REST Assured and Spring REST Docs, as shown in the following example:
 
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/howto/batch.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/howto/batch.adoc
@@ -30,7 +30,7 @@ See {spring-boot-autoconfigure-module-code}/batch/BatchAutoConfiguration.java[Ba
 
 
 [[howto.batch.running-from-the-command-line]]
-=== Running from the Command Line
+=== Running From the Command Line
 Spring Boot converts any command line argument starting with `--` to a property to add to the `Environment`, see <<features#features.external-config.command-line-args,accessing command line properties>>.
 This should not be used to pass arguments to batch jobs.
 To specify batch arguments on the command line, use the regular format (that is without `--`), as shown in the following example:
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/howto/build.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/howto/build.adoc
@@ -257,7 +257,7 @@ See {spring-boot-maven-plugin-docs}#run-example-debug[this example] for more det
 
 
 [[howto.build.build-an-executable-archive-with-ant-without-using-spring-boot-antlib]]
-=== Build an Executable Archive from Ant without Using spring-boot-antlib
+=== Build an Executable Archive From Ant without Using spring-boot-antlib
 To build with Ant, you need to grab dependencies, compile, and then create a jar or war archive.
 To make it executable, you can either use the `spring-boot-antlib` module or you can follow these instructions:
 
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/howto/webserver.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/howto/webserver.adoc
@@ -219,7 +219,7 @@ The details of the `h2` support depend on the chosen web server and the applicat
 
 
 [[howto.webserver.configure-http2.tomcat]]
-==== HTTP/2 with Tomcat
+==== HTTP/2 With Tomcat
 Spring Boot ships by default with Tomcat 9.0.x which supports `h2c` out of the box and `h2` out of the box when using JDK 9 or later.
 Alternatively, `h2` can be used on JDK 8 if the `libtcnative` library and its dependencies are installed on the host operating system.
 
@@ -239,7 +239,7 @@ This error is not fatal, and the application still starts with HTTP/1.1 SSL supp
 
 
 [[howto.webserver.configure-http2.jetty]]
-==== HTTP/2 with Jetty
+==== HTTP/2 With Jetty
 For HTTP/2 support, Jetty requires the additional `org.eclipse.jetty.http2:http2-server` dependency.
 To use `h2c` no other dependencies are required.
 To use `h2`, you also need to choose one of the following dependencies, depending on your deployment:
@@ -251,7 +251,7 @@ To use `h2`, you also need to choose one of the following dependencies, dependin
 
 
 [[howto.webserver.configure-http2.netty]]
-==== HTTP/2 with Reactor Netty
+==== HTTP/2 With Reactor Netty
 The `spring-boot-webflux-starter` is using by default Reactor Netty as a server.
 Reactor Netty supports `h2c` using JDK 8 or later with no additional dependencies.
 Reactor Netty supports `h2` using the JDK support with JDK 9 or later.
@@ -264,7 +264,7 @@ Developers can choose to import only the required dependencies using a classifie
 
 
 [[howto.webserver.configure-http2.undertow]]
-==== HTTP/2 with Undertow
+==== HTTP/2 With Undertow
 As of Undertow 1.4.0+, both `h2` and `h2c` are supported on JDK 8 without any additional dependencies.
 
 
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/io/jta.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/io/jta.adoc
@@ -1,5 +1,5 @@
 [[io.jta]]
-== Distributed Transactions with JTA
+== Distributed Transactions With JTA
 Spring Boot supports distributed JTA transactions across multiple XA resources by using an https://www.atomikos.com/[Atomikos] embedded transaction manager.
 JTA transactions are also supported when deploying to a suitable Java EE Application Server.
 
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/messaging/amqp.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/messaging/amqp.adoc
@@ -7,7 +7,7 @@ Spring Boot offers several conveniences for working with AMQP through RabbitMQ,
 
 
 [[messaging.amqp.rabbitmq]]
-=== RabbitMQ support
+=== RabbitMQ Support
 https://www.rabbitmq.com/[RabbitMQ] is a lightweight, reliable, scalable, and portable message broker based on the AMQP protocol.
 Spring uses `RabbitMQ` to communicate through the AMQP protocol.
 
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/upgrading/from-1x.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/upgrading/from-1x.adoc
@@ -1,5 +1,5 @@
 [[upgrading.from-1x]]
-== Upgrading from 1.x
+== Upgrading From 1.x
 
 If you are upgrading from the `1.x` release of Spring Boot, check the {github-wiki}/Spring-Boot-2.0-Migration-Guide["`migration guide`" on the project wiki] that provides detailed upgrade instructions.
 Check also the {github-wiki}["`release notes`"] for a list of "`new and noteworthy`" features for each release.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/upgrading/to-feature.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/upgrading/to-feature.adoc
@@ -1,5 +1,5 @@
 [[upgrading.to-feature]]
-== Upgrading to a new feature release
+== Upgrading to a New Feature Release
 
 When upgrading to a new feature release, some properties may have been renamed or removed.
 Spring Boot provides a way to analyze your application's environment and print diagnostics at startup, but also temporarily migrate properties at runtime for you.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/using/devtools.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/using/devtools.adoc
@@ -130,7 +130,7 @@ These work by rewriting classes as they are loaded to make them more amenable to
 
 
 [[using.devtools.restart.logging-condition-delta]]
-==== Logging changes in condition evaluation
+==== Logging Changes in Condition Evaluation
 By default, each time your application restarts, a report showing the condition evaluation delta is logged.
 The report shows the changes to your application's auto-configuration as you make changes such as adding or removing beans and setting configuration properties.
 
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/using/running-your-application.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/using/running-your-application.adoc
@@ -10,7 +10,7 @@ If you choose to package your application as a war file, see your server and IDE
 
 
 [[using.running-your-application.from-an-ide]]
-=== Running from an IDE
+=== Running From an IDE
 You can run a Spring Boot application from your IDE as a Java application.
 However, you first need to import your project.
 Import steps vary depending on your IDE and build system.
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/web/servlet.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/web/servlet.adoc
diff --git a/spring-boot-project/spring-boot-docs/src/docs/asciidoc/web/spring-security.adoc b/spring-boot-project/spring-boot-docs/src/docs/asciidoc/web/spring-security.adoc
