Merge pull request #10764 from Jay Bryant

* gh-10764:
  Wrap using-spring-boot.adoc at 90 characters
  Editorial changes to Using Spring Boot documentation

spring-boot-project/spring-boot-docs/src/main/asciidoc/using-spring-boot.adoc

@@ -4,48 +4,46 @@
 [partintro]
 --
 This section goes into more detail about how you should use Spring Boot. It covers topics
-such as build systems, auto-configuration and how to run your applications. We also cover
+such as build systems, auto-configuration, and how to run your applications. We also cover
 some Spring Boot best practices. Although there is nothing particularly special about
 Spring Boot (it is just another library that you can consume), there are a few
-recommendations that, when followed, will make your development process just a
-little easier.
+recommendations that, when followed, make your development process a little easier.
 
-If you're just starting out with Spring Boot, you should probably read the
-_<<getting-started.adoc#getting-started, Getting Started>>_ guide before diving into
-this section.
+If you are starting out with Spring Boot, you should probably read the
+_<<getting-started.adoc#getting-started, Getting Started>>_ guide before diving into this
+section.
 --
 
 
 
 [[using-boot-build-systems]]
-== Build systems
+== Build Systems
 It is strongly recommended that you choose a build system that supports
-<<using-boot-dependency-management,_dependency management_>>, and one
-that can consume artifacts published to the "`Maven Central`" repository. We
-would recommend that you choose Maven or Gradle. It is possible to get Spring Boot to
-work with other build systems (Ant for example), but they will not be particularly well
-supported.
+<<using-boot-dependency-management,_dependency management_>> and that can consume
+artifacts published to the "`Maven Central`" repository. We would recommend that you
+choose Maven or Gradle. It is possible to get Spring Boot to work with other build systems
+(Ant, for example), but they are not particularly well supported.
 
 
 
 [[using-boot-dependency-management]]
-=== Dependency management
-Each release of Spring Boot provides a curated list of dependencies it supports. In
-practice, you do not need to provide a version for any of these dependencies in your
-build configuration as Spring Boot is managing that for you. When you upgrade Spring
-Boot itself, these dependencies will be upgraded as well in a consistent way.
+=== Dependency Management
+Each release of Spring Boot provides a curated list of dependencies that it supports. In
+practice, you do not need to provide a version for any of these dependencies in your build
+configuration, as Spring Boot is managing that for you. When you upgrade Spring Boot
+itself, these dependencies are upgraded as well in a consistent way.
 
 NOTE: You can still specify a version and override Spring Boot's recommendations if you
-feel that's necessary.
+need to do so.
 
-The curated list contains all the spring modules that you can use with Spring Boot as
-well as a refined list of third party libraries. The list is available as a standard
+The curated list contains all the spring modules that you can use with Spring Boot as well
+as a refined list of third party libraries. The list is available as a standard
 <<using-boot-maven-without-a-parent,Bills of Materials (`spring-boot-dependencies`)>>
 that can be used with both <<using-boot-maven-parent-pom,Maven>> and
 <<using-boot-gradle,Gradle>>.
 
 WARNING: Each release of Spring Boot is associated with a base version of the Spring
-Framework so we **highly** recommend you to not specify its version on your own.
+Framework. We **highly** recommend that you not specify its version.
 
 
 
@@ -56,27 +54,29 @@ defaults. The parent project provides the following features:
 
 * Java 1.8 as the default compiler level.
 * UTF-8 source encoding.
-* A <<using-boot-dependency-management,Dependency Management section>>, allowing you to
-  omit `<version>` tags for common dependencies, inherited from the
-  `spring-boot-dependencies` POM.
-* Sensible https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html[resource filtering].
+* A <<using-boot-dependency-management,Dependency Management section>>, inherited from
+  the spring-boot-dependencies pom, that manages the versions of common dependencies. This
+  dependency management lets you omit <version> tags for those dependencies when used in
+  your own pom.
+* Sensible https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html[resource
+  filtering].
 * Sensible plugin configuration (http://www.mojohaus.org/exec-maven-plugin/[exec plugin],
-  https://github.com/ktoso/maven-git-commit-id-plugin[Git commit ID],
+  https://github.com/ktoso/maven-git-commit-id-plugin[Git commit ID], and
   http://maven.apache.org/plugins/maven-shade-plugin/[shade]).
 * Sensible resource filtering for `application.properties` and `application.yml` including
-  profile-specific files (e.g. `application-foo.properties` and `application-foo.yml`)
+  profile-specific files (for example, `application-foo.properties` and
+  `application-foo.yml`)
 
-On the last point: since the default config files accept
-Spring style placeholders (`${...}`) the Maven filtering is changed to
-use `@..@` placeholders (you can override that with a Maven property
-`resource.delimiter`).
+Note that, since the `application.properties` and `application.yml` files accept Spring
+style placeholders (`${...}`), the Maven filtering is changed to use `@..@` placeholders.
+(You can override that by setting a Maven property called `resource.delimiter`.)
 
 
 
 [[using-boot-maven-parent-pom]]
-==== Inheriting the starter parent
-To configure your project to inherit from the `spring-boot-starter-parent` simply set
-the `parent`:
+==== Inheriting the Starter Parent
+To configure your project to inherit from the `spring-boot-starter-parent` set
+the `parent`, as follows:
 
 [source,xml,indent=0,subs="verbatim,quotes,attributes"]
 ----
@@ -88,12 +88,12 @@ the `parent`:
 	</parent>
 ----
 
-NOTE: You should only need to specify the Spring Boot version number on this dependency.
+NOTE: You should need to specify only the Spring Boot version number on this dependency.
 If you import additional starters, you can safely omit the version number.
 
 With that setup, you can also override individual dependencies by overriding a property
-in your own project. For instance, to upgrade to another Spring Data release train you'd
-add the following to your `pom.xml`.
+in your own project. For instance, to upgrade to another Spring Data release train, you
+would add the following to your `pom.xml`:
 
 [source,xml,indent=0,subs="verbatim,quotes,attributes"]
 ----
@@ -108,14 +108,14 @@ for a list of supported properties.
 
 
 [[using-boot-maven-without-a-parent]]
-==== Using Spring Boot without the parent POM
+==== Using Spring Boot without the Parent POM
 Not everyone likes inheriting from the `spring-boot-starter-parent` POM. You may have your
-own corporate standard parent that you need to use, or you may just prefer to explicitly
+own corporate standard parent that you need to use or you may prefer to explicitly
 declare all your Maven configuration.
 
-If you don't want to use the `spring-boot-starter-parent`, you can still keep the benefit
+If you do not want to use the `spring-boot-starter-parent`, you can still keep the benefit
 of the dependency management (but not the plugin management) by using a `scope=import`
-dependency:
+dependency, as follows:
 
 [source,xml,indent=0,subs="verbatim,quotes,attributes"]
 ----
@@ -133,11 +133,11 @@ dependency:
 	</dependencyManagement>
 ----
 
-That setup does not allow you to override individual dependencies using a property as
-explained above. To achieve the same result, you'd need to add an entry in the
-`dependencyManagement` of your project **before** the `spring-boot-dependencies`
-entry. For instance, to upgrade to another Spring Data release train you'd add the
-following to your `pom.xml`.
+The preceding sample setup does not let you override individual dependencies by using a
+property, as explained above. To achieve the same result, you need to add an entry in the
+`dependencyManagement` of your project **before** the `spring-boot-dependencies` entry.
+For instance, to upgrade to another Spring Data release train, you could add the following
+element to your `pom.xml`:
 
 [source,xml,indent=0,subs="verbatim,quotes,attributes"]
 ----
@@ -162,16 +162,16 @@ following to your `pom.xml`.
 	</dependencyManagement>
 ----
 
-NOTE: In the example above, we specify a _BOM_ but any dependency type can be overridden
-that way.
+NOTE: In the preceding example, we specify a _BOM_, but any dependency type can be
+overridden in the same way.
 
 
 
 [[using-boot-maven-plugin]]
-==== Using the Spring Boot Maven plugin
-Spring Boot includes a <<build-tool-plugins.adoc#build-tool-plugins-maven-plugin, Maven plugin>>
-that can package the project as an executable jar. Add the plugin to your `<plugins>`
-section if you want to use it:
+==== Using the Spring Boot Maven Plugin
+Spring Boot includes a <<build-tool-plugins.adoc#build-tool-plugins-maven-plugin, Maven
+plugin>> that can package the project as an executable jar. Add the plugin to your
+`<plugins>` section if you want to use it, as shown in the following example:
 
 [source,xml,indent=0,subs="verbatim,quotes,attributes"]
 ----
@@ -185,9 +185,9 @@ section if you want to use it:
 	</build>
 ----
 
-NOTE: If you use the Spring Boot starter parent pom, you only need to add the plugin,
-there is no need for to configure it unless you want to change the settings defined in
-the parent.
+NOTE: If you use the Spring Boot starter parent pom, you need to add only the plugin.
+There is no need to configure it unless you want to change the settings defined in the
+parent.
 
 
 
@@ -206,7 +206,8 @@ It is possible to build a Spring Boot project using Apache Ant+Ivy. The
 `spring-boot-antlib` "`AntLib`" module is also available to help Ant create executable
 jars.
 
-To declare dependencies a typical `ivy.xml` file will look something like this:
+To declare dependencies, a typical `ivy.xml` file looks something like the following
+example:
 
 [source,xml,indent=0]
 ----
@@ -223,7 +224,7 @@ To declare dependencies a typical `ivy.xml` file will look something like this:
 	</ivy-module>
 ----
 
-A typical `build.xml` will look like this:
+A typical `build.xml` looks like the following example:
 
 [source,xml,indent=0,subs="verbatim,quotes,attributes"]
 ----
@@ -262,19 +263,18 @@ A typical `build.xml` will look like this:
 	</project>
 ----
 
-TIP: See the _<<howto.adoc#howto-build-an-executable-archive-with-ant>>_ "`How-to`" if
-you don't want to use the `spring-boot-antlib` module.
+TIP: If you do not want to use the `spring-boot-antlib` module, see the
+_<<howto.adoc#howto-build-an-executable-archive-with-ant>>_ "`How-to`" .
 
 
 
 [[using-boot-starter]]
 === Starters
 Starters are a set of convenient dependency descriptors that you can include in your
-application. You get a one-stop-shop for all the Spring and related technology that you
-need, without having to hunt through sample code and copy paste loads of dependency
+application. You get a one-stop shop for all the Spring and related technology that you
+need without having to hunt through sample code and copy-paste loads of dependency
 descriptors. For example, if you want to get started using Spring and JPA for database
-access, just include the `spring-boot-starter-data-jpa` dependency in your project, and
-you are good to go.
+access, include the `spring-boot-starter-data-jpa` dependency in your project.
 
 The starters contain a lot of the dependencies that you need to get a project up and
 running quickly and with a consistent, supported set of managed transitive dependencies.
@@ -288,10 +288,11 @@ search dependencies by name. For example, with the appropriate Eclipse or STS pl
 installed, you can simply hit `ctrl-space` in the POM editor and type
 "`spring-boot-starter`" for a complete list.
 
-As explained in the <<spring-boot-features#boot-features-custom-starter,Creating your own starter>>
-section, third party starters should not start with `spring-boot` as it is reserved for
-official Spring Boot artifacts. A third-party starter for `acme` will be typically named
-`acme-spring-boot-starter`.
+As explained in the <<spring-boot-features#boot-features-custom-starter,Creating Your Own
+Starter>> section, third party starters should not start with `spring-boot`, as it is
+reserved for official Spring Boot artifacts. Rather, a third-party starter typically
+starts with the name of the project. For example, a third-party starter project called
+`thirdpartyproject` would typically be named `thirdpartyproject-spring-boot-starter`.
 ****
 
 The following application starters are provided by Spring Boot under the
@@ -306,51 +307,52 @@ _<<production-ready-features.adoc#production-ready, production ready>>_ features
 .Spring Boot production starters
 include::../../../target/generated-resources/production-starters.adoc[]
 
-Finally, Spring Boot also includes some starters that can be used if you want to exclude
+Finally, Spring Boot also includes the following starters that can be used if you want to
+exclude
 or swap specific technical facets:
 
 .Spring Boot technical starters
 include::../../../target/generated-resources/technical-starters.adoc[]
 
 TIP: For a list of additional community contributed starters, see the
-{github-master-code}/spring-boot-project/spring-boot-starters/README.adoc[README file] in the
-`spring-boot-starters` module on GitHub.
+{github-master-code}/spring-boot-project/spring-boot-starters/README.adoc[README file] in
+the `spring-boot-starters` module on GitHub.
 
 
 
 [[using-boot-structuring-your-code]]
-== Structuring your code
-Spring Boot does not require any specific code layout to work, however, there are some
+== Structuring Your Code
+Spring Boot does not require any specific code layout to work. However, there are some
 best practices that help.
 
 
 
 [[using-boot-using-the-default-package]]
-=== Using the "`default`" package
-When a class doesn't include a `package` declaration it is considered to be in the
-"`default package`". The use of the "`default package`" is generally discouraged, and
+=== Using the "`default`" Package
+When a class does not include a `package` declaration, it is considered to be in the
+"`default package`". The use of the "`default package`" is generally discouraged and
 should be avoided. It can cause particular problems for Spring Boot applications that
-use `@ComponentScan`, `@EntityScan` or `@SpringBootApplication` annotations, since every
-class from every jar, will be read.
+use the `@ComponentScan`, `@EntityScan`, or `@SpringBootApplication` annotations, since
+every class from every jar is read.
 
-TIP: We recommend that you follow Java's recommended package naming conventions
-and use a reversed domain name (for example, `com.example.project`).
+TIP: We recommend that you follow Java's recommended package naming conventions and use a
+reversed domain name (for example, `com.example.project`).
 
 
 
 [[using-boot-locating-the-main-class]]
-=== Locating the main application class
+=== Locating the Main Application Class
 We generally recommend that you locate your main application class in a root package
 above other classes. The `@EnableAutoConfiguration` annotation is often placed on your
 main class, and it implicitly defines a base "`search package`" for certain items. For
 example, if you are writing a JPA application, the package of the
-`@EnableAutoConfiguration` annotated class will be used to search for `@Entity` items.
+`@EnableAutoConfiguration` annotated class is used to search for `@Entity` items.
 
-Using a root package also allows the `@ComponentScan` annotation to be used without
-needing to specify a `basePackage` attribute. You can also use the
-`@SpringBootApplication` annotation if your main class is in the root package.
+Using a root package also lets the `@ComponentScan` annotation be used without needing to
+specify a `basePackage` attribute. You can also use the `@SpringBootApplication`
+annotation if your main class is in the root package.
 
-Here is a typical layout:
+The following listing shows a typical layout:
 
 [indent=0]
 ----
@@ -373,7 +375,7 @@ Here is a typical layout:
 ----
 
 The `Application.java` file would declare the `main` method, along with the basic
-`@Configuration`.
+`@Configuration`, as follows:
 
 [source,java,indent=0]
 ----
@@ -399,32 +401,32 @@ The `Application.java` file would declare the `main` method, along with the basi
 
 
 [[using-boot-configuration-classes]]
-== Configuration classes
+== Configuration Classes
 Spring Boot favors Java-based configuration. Although it is possible to use
-`SpringApplication` with an XML sources, we generally recommend that your primary
-source is a single `@Configuration` class. Usually the class that defines the `main`
-method is also a good candidate as the primary `@Configuration`.
+`SpringApplication` with XML sources, we generally recommend that your primary source be a
+single `@Configuration` class. Usually the class that defines the `main` method is a good
+candidate as the primary `@Configuration`.
 
 TIP: Many Spring configuration examples have been published on the Internet that use XML
-configuration. Always try to use the equivalent Java-based configuration if possible.
+configuration. If possible, always try to use the equivalent Java-based configuration.
 Searching for `+Enable*+` annotations can be a good starting point.
 
 
 
 [[using-boot-importing-configuration]]
-=== Importing additional configuration classes
-You don't need to put all your `@Configuration` into a single class. The `@Import`
-annotation can be used to import additional configuration classes. Alternatively, you
-can use `@ComponentScan` to automatically pick up all Spring components, including
+=== Importing Additional Configuration Classes
+You need not put all your `@Configuration` into a single class. The `@Import` annotation
+can be used to import additional configuration classes. Alternatively, you can use
+`@ComponentScan` to automatically pick up all Spring components, including
 `@Configuration` classes.
 
 
 
 [[using-boot-importing-xml-configuration]]
-=== Importing XML configuration
+=== Importing XML Configuration
 If you absolutely must use XML based configuration, we recommend that you still start
-with a `@Configuration` class. You can then use an additional `@ImportResource`
-annotation to load XML configuration files.
+with a `@Configuration` class. You can then use an `@ImportResource` annotation to load
+XML configuration files.
 
 
 
@@ -433,7 +435,7 @@ annotation to load XML configuration files.
 Spring Boot auto-configuration attempts to automatically configure your Spring
 application based on the jar dependencies that you have added. For example, if
 `HSQLDB` is on your classpath, and you have not manually configured any database
-connection beans, then we will auto-configure an in-memory database.
+connection beans, then Spring Boot auto-configures an in-memory database.
 
 You need to opt-in to auto-configuration by adding the `@EnableAutoConfiguration` or
 `@SpringBootApplication` annotations to one of your `@Configuration` classes.
@@ -444,21 +446,22 @@ recommend that you add it to your primary `@Configuration` class.
 
 
 [[using-boot-replacing-auto-configuration]]
-=== Gradually replacing auto-configuration
-Auto-configuration is noninvasive,  at any point you can start to define your own
-configuration to replace specific parts of the auto-configuration. For example, if
-you add your own `DataSource` bean, the default embedded database support will back away.
+=== Gradually Replacing Auto-configuration
+Auto-configuration is noninvasive. At any point, you can start to define your own
+configuration to replace specific parts of the auto-configuration. For example, if you add
+your own `DataSource` bean, the default embedded database support backs away.
 
-If you need to find out what auto-configuration is currently being applied, and why,
-start your application with the `--debug` switch. This will enable debug logs for a
-selection of core loggers and log an auto-configuration report to the console.
+If you need to find out what auto-configuration is currently being applied, and why, start
+your application with the `--debug` switch. Doing so enables debug logs for a selection of
+core loggers and logs an auto-configuration report to the console.
 
 
 
 [[using-boot-disabling-specific-auto-configuration]]
-=== Disabling specific auto-configuration
-If you find that specific auto-configure classes are being applied that you don't want,
-you can use the exclude attribute of `@EnableAutoConfiguration` to disable them.
+=== Disabling Specific Auto-configuration Classes
+If you find that specific auto-configuration classes that you do not want are being
+applied, you can use the exclude attribute of `@EnableAutoConfiguration` to disable them,
+as shown in the following example:
 
 [source,java,indent=0]
 ----
@@ -472,26 +475,26 @@ you can use the exclude attribute of `@EnableAutoConfiguration` to disable them.
 	}
 ----
 
-If the class is not on the classpath, you can use the `excludeName` attribute of
-the annotation and specify the fully qualified name instead. Finally, you can also
-control the list of auto-configuration classes to exclude via the
-`spring.autoconfigure.exclude` property.
+If the class is not on the classpath, you can use the `excludeName` attribute of the
+annotation and specify the fully qualified name instead. Finally, you can also control the
+list of auto-configuration classes to exclude by using the `spring.autoconfigure.exclude`
+property.
 
-TIP: You can define exclusions both at the annotation level and using the property.
+TIP: You can define exclusions both at the annotation level and by using the property.
 
 [[using-boot-spring-beans-and-dependency-injection]]
-== Spring Beans and dependency injection
+== Spring Beans and Dependency Injection
 You are free to use any of the standard Spring Framework techniques to define your beans
 and their injected dependencies. For simplicity, we often find that using `@ComponentScan`
-to find your beans, in combination with `@Autowired` constructor injection works well.
+(to find your beans) and using `@Autowired` (to do constructor injection) works well.
 
 If you structure your code as suggested above (locating your application class in a root
 package), you can add `@ComponentScan` without any arguments. All of your application
-components (`@Component`, `@Service`, `@Repository`, `@Controller` etc.) will be
+components (`@Component`, `@Service`, `@Repository`, `@Controller` etc.) are
 automatically registered as Spring Beans.
 
-Here is an example `@Service` Bean that uses constructor injection to obtain a
-required `RiskAssessor` bean.
+The following example shows a `@Service` Bean that uses constructor injection to obtain a
+required `RiskAssessor` bean:
 
 [source,java,indent=0]
 ----
@@ -515,7 +518,8 @@ required `RiskAssessor` bean.
 	}
 ----
 
-And if a bean has one constructor, you can omit the `@Autowired`.
+If a bean has one constructor, you can omit the `@Autowired`, as shown in the following
+example:
 
 [source,java,indent=0]
 ----
@@ -533,20 +537,22 @@ And if a bean has one constructor, you can omit the `@Autowired`.
 	}
 ----
 
-TIP: Notice how using constructor injection allows the `riskAssessor` field to be marked
-as `final`, indicating that it cannot be subsequently changed.
+TIP: Notice how using constructor injection lets the `riskAssessor` field be marked as
+`final`, indicating that it cannot be subsequently changed.
 
 
 
 [[using-boot-using-springbootapplication-annotation]]
-== Using the @SpringBootApplication annotation
+== Using the @SpringBootApplication Annotation
 Many Spring Boot developers always have their main class annotated with `@Configuration`,
-`@EnableAutoConfiguration` and `@ComponentScan`. Since these annotations are so frequently
-used together (especially if you follow the <<using-boot-structuring-your-code, best practices>>
-above), Spring Boot provides a convenient `@SpringBootApplication` alternative.
+`@EnableAutoConfiguration`, and `@ComponentScan`. Since these annotations are so frequently
+used together (especially if you follow the <<using-boot-structuring-your-code, best
+practices>> above), Spring Boot provides a convenient `@SpringBootApplication`
+alternative.
 
 The `@SpringBootApplication` annotation is equivalent to using `@Configuration`,
-`@EnableAutoConfiguration` and `@ComponentScan` with their default attributes:
+`@EnableAutoConfiguration`, and `@ComponentScan` with their default attributes, as shown
+in the following example:
 
 
 [source,java,indent=0]
@@ -572,39 +578,39 @@ NOTE: `@SpringBootApplication` also provides aliases to customize the attributes
 
 
 [[using-boot-running-your-application]]
-== Running your application
-One of the biggest advantages of packaging your application as jar and using an embedded
+== Running Your Application
+One of the biggest advantages of packaging your application as a jar and using an embedded
 HTTP server is that you can run your application as you would any other. Debugging Spring
-Boot applications is also easy; you don't need any special IDE plugins or extensions.
+Boot applications is also easy. You do not need any special IDE plugins or extensions.
 
-NOTE: This section only covers jar based packaging, if you choose to package your
-application as a war file you should refer to your server and IDE documentation.
+NOTE: This section only covers jar based packaging. If you choose to package your
+application as a war file, you should refer to your server and IDE documentation.
 
 
 
 [[using-boot-running-from-an-ide]]
 === Running from an IDE
-You can run a Spring Boot application from your IDE as a simple Java application, however,
-first you will need to import your project. Import steps will vary depending on your IDE
-and build system. Most IDEs can import Maven projects directly, for example Eclipse users
-can select `Import...` -> `Existing Maven Projects` from the `File` menu.
+You can run a Spring Boot application from your IDE as a simple Java application. However,
+you first need to import your project. Import steps vary depending on your IDE and build
+system. Most IDEs can import Maven projects directly. For example, Eclipse users can
+select `Import...` -> `Existing Maven Projects` from the `File` menu.
 
-If you can't directly import your project into your IDE, you may be able to generate IDE
-metadata using a build plugin. Maven includes plugins for
+If you cannot directly import your project into your IDE, you may be able to generate IDE
+metadata by using a build plugin. Maven includes plugins for
 http://maven.apache.org/plugins/maven-eclipse-plugin/[Eclipse] and
-http://maven.apache.org/plugins/maven-idea-plugin/[IDEA]; Gradle offers plugins
-for {gradle-user-guide}/userguide.html[various IDEs].
+http://maven.apache.org/plugins/maven-idea-plugin/[IDEA]. Gradle offers plugins for
+{gradle-user-guide}/userguide.html[various IDEs].
 
-TIP: If you accidentally run a web application twice you will see a "`Port already in
-use`" error. STS users can use the `Relaunch` button rather than `Run` to ensure that
+TIP: If you accidentally run a web application twice, you see a "`Port already in use`"
+error. STS users can use the `Relaunch` button rather than the `Run` button to ensure that
 any existing instance is closed.
 
 
 
 [[using-boot-running-as-a-packaged-application]]
-=== Running as a packaged application
-If you use the Spring Boot Maven or Gradle plugins to create an executable jar you can
-run your application using `java -jar`. For example:
+=== Running as a Packaged Application
+If you use the Spring Boot Maven or Gradle plugins to create an executable jar, you can
+run your application using `java -jar`, as shown in the following example:
 
 [indent=0,subs="attributes"]
 ----
@@ -612,7 +618,8 @@ run your application using `java -jar`. For example:
 ----
 
 It is also possible to run a packaged application with remote debugging support enabled.
-This allows you to attach a debugger to your packaged application:
+Doing so lets you attach a debugger to your packaged application, as shown in the
+following example:
 
 [indent=0,subs="attributes"]
 ----
@@ -623,16 +630,17 @@ This allows you to attach a debugger to your packaged application:
 
 
 [[using-boot-running-with-the-maven-plugin]]
-=== Using the Maven plugin
-The Spring Boot Maven plugin includes a `run` goal which can be used to quickly compile
-and run your application. Applications run in an exploded form just like in your IDE.
+=== Using the Maven Plugin
+The Spring Boot Maven plugin includes a `run` goal that can be used to quickly compile
+and run your application. Applications run in an exploded form, as they do in your IDE.
 
 [indent=0,subs="attributes"]
 ----
 	$ mvn spring-boot:run
 ----
 
-You might also want to use the useful operating system environment variable:
+You might also want to use the `MAVEN_OPTS` operating system environment variable, as
+shown in the following example:
 
 [indent=0,subs="attributes"]
 ----
@@ -642,17 +650,18 @@ You might also want to use the useful operating system environment variable:
 
 
 [[using-boot-running-with-the-gradle-plugin]]
-=== Using the Gradle plugin
-The Spring Boot Gradle plugin also includes a `bootRun` task which can be used to run
-your application in an exploded form. The `bootRun` task is added whenever you apply the
-the `org.springframework.boot` and `java` plugins:
+=== Using the Gradle Plugin
+The Spring Boot Gradle plugin also includes a `bootRun` task that can be used to run your
+application in an exploded form. The `bootRun` task is added whenever you apply
+the `org.springframework.boot` and `java` plugins and is shown in the following example:
 
 [indent=0,subs="attributes"]
 ----
 	$ gradle bootRun
 ----
 
-You might also want to use this useful operating system environment variable:
+You might also want to use the `JAVA_OPTS` operating system environment variable, as shown
+in the following example:
 
 [indent=0,subs="attributes"]
 ----
@@ -662,24 +671,26 @@ You might also want to use this useful operating system environment variable:
 
 
 [[using-boot-hot-swapping]]
-=== Hot swapping
+=== Hot Swapping
 Since Spring Boot applications are just plain Java applications, JVM hot-swapping should
 work out of the box. JVM hot swapping is somewhat limited with the bytecode that it can
-replace, for a more complete solution
-http://zeroturnaround.com/software/jrebel/[JRebel] can be used. The
-`spring-boot-devtools` module also includes support for quick application restarts.
+replace. For a more complete solution,
+http://zeroturnaround.com/software/jrebel/[JRebel] can be used.
 
+The
+`spring-boot-devtools` module also includes support for quick application restarts.
 See the <<using-boot-devtools>> section below and the
 <<howto.adoc#howto-hotswapping, Hot swapping "`How-to`">> for details.
 
 
 
 [[using-boot-devtools]]
-== Developer tools
+== Developer Tools
 Spring Boot includes an additional set of tools that can make the application
 development experience a little more pleasant. The `spring-boot-devtools` module can be
 included in any project to provide additional development-time features. To include
-devtools support, simply add the module dependency to your build:
+devtools support, add the module dependency to your build, as shown in the following
+listings for Maven and Gradle:
 
 .Maven
 [source,xml,indent=0,subs="verbatim,quotes,attributes"]
@@ -702,97 +713,97 @@ devtools support, simply add the module dependency to your build:
 ----
 
 NOTE: Developer tools are automatically disabled when running a fully packaged
-application. If your application is launched using `java -jar` or if it's started using a
+application. If your application is launched using `java -jar` or if it is started from a
 special classloader, then it is considered a "`production application`". Flagging the
 dependency as optional is a best practice that prevents devtools from being transitively
 applied to other modules using your project. Gradle does not support `optional`
-dependencies out-of-the-box so you may want to have a look to the
-{propdeps-plugin}[`propdeps-plugin`] in the meantime.
+dependencies out-of-the-box, so you may want to have a look at the
+{propdeps-plugin}[`propdeps-plugin`].
 
-TIP: repackaged archives do not contain devtools by default. If you want to use
-<<using-boot-devtools-remote,certain remote devtools feature>>, you'll need to disable the
+TIP: Repackaged archives do not contain devtools by default. If you want to use a
+<<using-boot-devtools-remote,certain remote devtools feature>>, you need to disable the
 `excludeDevtools` build property to include it. The property is supported with both the
 Maven and Gradle plugins.
 
 
 
 [[using-boot-devtools-property-defaults]]
-=== Property defaults
+=== Property Defaults
 Several of the libraries supported by Spring Boot use caches to improve performance. For
-example, <<spring-boot-features#boot-features-spring-mvc-template-engines,template engines>>
-will cache compiled templates to avoid repeatedly parsing template files.
-Also, Spring MVC can add HTTP caching headers to responses when serving static resources.
+example, <<spring-boot-features#boot-features-spring-mvc-template-engines,template
+engines>> cache compiled templates to avoid repeatedly parsing template files. Also,
+Spring MVC can add HTTP caching headers to responses when serving static resources.
 
-Whilst caching is very beneficial in production, it can be counter productive during
+While caching is very beneficial in production, it can be counter-productive during
 development, preventing you from seeing the changes you just made in your application.
-For this reason, spring-boot-devtools will disable those caching options by default.
+For this reason, spring-boot-devtools disables the caching options by default.
 
 Cache options are usually configured by settings in your `application.properties` file.
 For example, Thymeleaf offers the `spring.thymeleaf.cache` property. Rather than needing
-to set these properties manually, the `spring-boot-devtools` module will automatically
-apply sensible development-time configuration.
+to set these properties manually, the `spring-boot-devtools` module automatically applies
+sensible development-time configuration.
 
-TIP: For a complete list of the properties that are applied see
+TIP: For a complete list of the properties that are applied by the devtools, see
 {sc-spring-boot-devtools}/env/DevToolsPropertyDefaultsPostProcessor.{sc-ext}[DevToolsPropertyDefaultsPostProcessor].
 
 
 
 [[using-boot-devtools-restart]]
-=== Automatic restart
-Applications that use `spring-boot-devtools` will automatically restart whenever files
-on the classpath change. This can be a useful feature when working in an IDE as it gives
-a very fast feedback loop for code changes. By default, any entry on the classpath that
-points to a folder will be monitored for changes. Note that certain resources such as
-static assets and view templates <<using-boot-devtools-restart-exclude, do not need to
-restart the application>>.
+=== Automatic Restart
+Applications that use `spring-boot-devtools` automatically restart whenever files on the
+classpath change. This can be a useful feature when working in an IDE, as it gives a very
+fast feedback loop for code changes. By default, any entry on the classpath that points to
+a folder is monitored for changes. Note that certain resources, such as static assets and
+view templates, <<using-boot-devtools-restart-exclude, do not need to restart the
+application>>.
 
 .Triggering a restart
 ****
 As DevTools monitors classpath resources, the only way to trigger a restart is to update
 the classpath. The way in which you cause the classpath to be updated depends on the IDE
-that you are using. In Eclipse, saving a modified file will cause the classpath to be
-updated and trigger a restart. In IntelliJ IDEA, building the project (`Build +->+ Make
-Project`) will have the same effect.
+that you are using. In Eclipse, saving a modified file causes the classpath to be updated
+and triggers a restart. In IntelliJ IDEA, building the project (`Build +->+ Make Project`)
+will have the same effect.
 ****
 
 [NOTE]
 ====
-You can also start your application via the supported build plugins (i.e. Maven and
-Gradle) as long as forking is enabled since DevTools need an isolated application
-classloader to operate properly. Gradle and Maven do that by default when they detect
-DevTools on the classpath.
+As long as forking is enabled, you can also start your application by using the supported
+build plugins (Maven and Gradle), since DevTools needs an isolated application classloader
+to operate properly. By default, Gradle and Maven do that when they detect DevTools on the
+classpath.
 
 ====
 
 TIP: Automatic restart works very well when used with LiveReload.
-<<using-boot-devtools-livereload,See below>> for details. If you use JRebel automatic
-restarts will be disabled in favor of dynamic class reloading. Other devtools features
-(such as LiveReload and property overrides) can still be used.
+<<using-boot-devtools-livereload,See the LiveReload section>> for details. If you use
+JRebel, automatic restarts are disabled in favor of dynamic class reloading. Other
+devtools features (such as LiveReload and property overrides) can still be used.
 
 NOTE: DevTools relies on the application context's shutdown hook to close it during a
-restart. It will not work correctly if you have disabled the shutdown hook (
-`SpringApplication.setRegisterShutdownHook(false)`).
+restart. It does not work correctly if you have disabled the shutdown hook
+(`SpringApplication.setRegisterShutdownHook(false)`).
 
 NOTE: When deciding if an entry on the classpath should trigger a restart when it changes,
 DevTools automatically ignores projects named `spring-boot`, `spring-boot-devtools`,
 `spring-boot-autoconfigure`, `spring-boot-actuator`, and `spring-boot-starter`.
 
-NOTE: DevTools needs to customize the `ResourceLoader` used by the `ApplicationContext`:
-if your application provides one already, it is going to be wrapped. Direct override of
+NOTE: DevTools needs to customize the `ResourceLoader` used by the `ApplicationContext`.
+If your application provides one already, it is going to be wrapped. Direct override of
 the `getResource` method on the `ApplicationContext` is not supported.
 
 [[using-spring-boot-restart-vs-reload]]
 .Restart vs Reload
 ****
-The restart technology provided by Spring Boot works by using two classloaders.
-Classes that don't change (for example, those from third-party jars) are loaded into a
-_base_ classloader. Classes that you're actively developing are loaded into a _restart_
+The restart technology provided by Spring Boot works by using two classloaders. Classes
+that do not change (for example, those from third-party jars) are loaded into a _base_
+classloader. Classes that you are actively developing are loaded into a _restart_
 classloader. When the application is restarted, the _restart_ classloader is thrown away
 and a new one is created. This approach means that application restarts are typically much
-faster than "`cold starts`" since the _base_ classloader is already available and
+faster than "`cold starts`", since the _base_ classloader is already available and
 populated.
 
-If you find that restarts aren't quick enough for your applications, or you encounter
+If you find that restarts are not quick enough for your applications or you encounter
 classloading issues, you could consider reloading technologies such as
 http://zeroturnaround.com/software/jrebel/[JRebel] from ZeroTurnaround. These work by
 rewriting classes as they are loaded to make them more amenable to reloading.
@@ -801,46 +812,47 @@ rewriting classes as they are loaded to make them more amenable to reloading.
 
 
 [[using-boot-devtools-restart-exclude]]
-==== Excluding resources
-Certain resources don't necessarily need to trigger a restart when they are changed. For
-example, Thymeleaf templates can just be edited in-place. By default changing resources
-in `/META-INF/maven`, `/META-INF/resources`, `/resources`, `/static`, `/public` or
-`/templates` will not trigger a restart but will trigger a
-<<using-boot-devtools-livereload, live reload>>. If you want to customize these exclusions
+==== Excluding Resources
+Certain resources do not necessarily need to trigger a restart when they are changed. For
+example, Thymeleaf templates can be edited in-place. By default, changing resources
+in `/META-INF/maven`, `/META-INF/resources`, `/resources`, `/static`, `/public`, or
+`/templates` does not trigger a restart but does trigger a
+<<using-boot-devtools-livereload, live reload>>. If you want to customize these exclusions,
 you can use the `spring.devtools.restart.exclude` property. For example, to exclude only
-`/static` and `/public` you would set the following:
+`/static` and `/public` you would set the following property:
 
 [indent=0]
 ----
 	spring.devtools.restart.exclude=static/**,public/**
 ----
 
-TIP: if you want to keep those defaults and _add_ additional exclusions, use the
+TIP: If you want to keep those defaults and _add_ additional exclusions, use the
 `spring.devtools.restart.additional-exclude` property instead.
 
 
 [[using-boot-devtools-restart-additional-paths]]
-==== Watching additional paths
+==== Watching Additional Paths
 You may want your application to be restarted or reloaded when you make changes to files
 that are not on the classpath. To do so, use the
 `spring.devtools.restart.additional-paths` property to configure additional paths to watch
 for changes. You can use the `spring.devtools.restart.exclude` property
 <<using-boot-devtools-restart-exclude, described above>> to control whether changes
-beneath the additional paths will trigger a full restart or just a
+beneath the additional paths trigger a full restart or a
 <<using-boot-devtools-livereload, live reload>>.
 
 
 
 [[using-boot-devtools-restart-disable]]
-==== Disabling restart
-If you don't want to use the restart feature you can disable it using the
-`spring.devtools.restart.enabled` property. In most cases you can set this in your
-`application.properties` (this will still initialize the restart classloader but it won't
+==== Disabling Restart
+If you do not want to use the restart feature, you can disable it by using the
+`spring.devtools.restart.enabled` property. In most cases, you can set this property in your
+`application.properties` (doing so still initializes the restart classloader, but it does not
 watch for file changes).
 
-If you need to _completely_ disable restart support, for example, because it doesn't work
-with a specific library, you need to set a `System` property before calling
-`SpringApplication.run(...)`. For example:
+If you need to _completely_ disable restart support (for example, because it doesn't work
+with a specific library), you need to set the `spring.devtools.restart.enabled` `System`
+property to `false` before calling `SpringApplication.run(...)`, as shown in the following
+example:
 
 [source,java,indent=0]
 ----
@@ -853,40 +865,39 @@ with a specific library, you need to set a `System` property before calling
 
 
 [[using-boot-devtools-restart-triggerfile]]
-==== Using a trigger file
+==== Using a Trigger File
 If you work with an IDE that continuously compiles changed files, you might prefer to
-trigger restarts only at specific times. To do this you can use a "`trigger file`", which
+trigger restarts only at specific times. To do so, you can use a "`trigger file`", which
 is a special file that must be modified when you want to actually trigger a restart check.
 Changing the file only triggers the check and the restart will only occur if Devtools has
-detected it has to do something. The trigger file could be updated manually, or via an IDE
+detected it has to do something. The trigger file can be updated manually or via an IDE
 plugin.
 
-To use a trigger file use the `spring.devtools.restart.trigger-file` property.
+To use a trigger file, set the `spring.devtools.restart.trigger-file` property to the path
+of your trigger file.
 
 TIP: You might want to set `spring.devtools.restart.trigger-file` as a
-<<using-boot-devtools-globalsettings,global setting>> so that all your projects behave
+<<using-boot-devtools-globalsettings,global setting>>, so that all your projects behave
 in the same way.
 
 
 
 [[using-boot-devtools-customizing-classload]]
-==== Customizing the restart classloader
+==== Customizing the Restart Classloader
 As described in the <<using-spring-boot-restart-vs-reload>> section above, restart
-functionality is implemented by using two classloaders. For most applications this
-approach works well, however, sometimes it can cause classloading issues.
+functionality is implemented by using two classloaders. For most applications, this
+approach works well. However, sometimes it can cause classloading issues.
 
-By default, any open project in your IDE will be loaded using the "`restart`" classloader,
-and any regular `.jar` file will be loaded using the "`base`" classloader. If you work on
-a multi-module project, and not each module is imported into your IDE, you may need to
-customize things. To do this you can create a `META-INF/spring-devtools.properties` file.
+By default, any open project in your IDE is loaded with the "`restart`" classloader, and
+any regular `.jar` file is loaded with the "`base`" classloader. If you work on a
+multi-module project, and not every module is imported into your IDE, you may need to
+customize things. To do so, you can create a `META-INF/spring-devtools.properties` file.
 
-The `spring-devtools.properties` file can contain `restart.exclude.` and
-`restart.include.` prefixed properties. The `include` elements are items that should be
+The `spring-devtools.properties` file can contain properties prefixed with
+`restart.exclude` and `restart.include`. The `include` elements are items that should be
 pulled up into the "`restart`" classloader, and the `exclude` elements are items that
 should be pushed down into the "`base`" classloader. The value of the property is a regex
-pattern that will be applied to the classpath.
-
-For example:
+pattern that is applied to the classpath, as shown in the following example:
 
 [source,properties,indent=0]
 ----
@@ -895,7 +906,7 @@ For example:
 ----
 
 NOTE: All property keys must be unique. As long as a property starts with
-`restart.include.` or `restart.exclude.` it will be considered.
+`restart.include.` or `restart.exclude.` it is considered.
 
 TIP: All `META-INF/spring-devtools.properties` from the classpath will be loaded. You can
 package files inside your project, or in the libraries that the project consumes.
@@ -903,14 +914,14 @@ package files inside your project, or in the libraries that the project consumes
 
 
 [[using-boot-devtools-known-restart-limitations]]
-==== Known limitations
-Restart functionality does not work well with objects that are deserialized using a
-standard `ObjectInputStream`. If you need to deserialize data, you may need to use Spring's
-`ConfigurableObjectInputStream` in combination with
+==== Known Limitations
+Restart functionality does not work well with objects that are deserialized by using a
+standard `ObjectInputStream`. If you need to deserialize data, you may need to use
+Spring's `ConfigurableObjectInputStream` in combination with
 `Thread.currentThread().getContextClassLoader()`.
 
 Unfortunately, several third-party libraries deserialize without considering the context
-classloader. If you find such a problem, you will need to request a fix with the original
+classloader. If you find such a problem, you need to request a fix with the original
 authors.
 
 
@@ -922,23 +933,23 @@ to trigger a browser refresh when a resource is changed. LiveReload browser exte
 freely available for Chrome, Firefox and Safari from
 http://livereload.com/extensions/[livereload.com].
 
-If you don't want to start the LiveReload server when your application runs you can set
+If you do not want to start the LiveReload server when your application runs, you can set
 the `spring.devtools.livereload.enabled` property to `false`.
 
 NOTE: You can only run one LiveReload server at a time. Before starting your application,
 ensure that no other LiveReload servers are running. If you start multiple applications
-from your IDE, only the first will have LiveReload support.
+from your IDE, only the first has LiveReload support.
 
 
 
 [[using-boot-devtools-globalsettings]]
-=== Global settings
+=== Global Settings
 You can configure global devtools settings by adding a file named
 `.spring-boot-devtools.properties` to your `$HOME` folder (note that the filename starts
-with "`.`"). Any properties added to this file will apply to _all_ Spring Boot
-applications on your machine that use devtools. For example, to configure restart to
-always use a <<using-boot-devtools-restart-triggerfile, trigger file>>, you would add
-the following:
+with "`.`"). Any properties added to this file apply to _all_ Spring Boot applications on
+your machine that use devtools. For example, to configure restart to always use a
+<<using-boot-devtools-restart-triggerfile, trigger file>>, you would add the following
+property:
 
 .~/.spring-boot-devtools.properties
 [source,properties,indent=0]
@@ -949,10 +960,11 @@ the following:
 
 
 [[using-boot-devtools-remote]]
-=== Remote applications
+=== Remote Applications
 The Spring Boot developer tools are not just limited to local development. You can also
-use several features when running applications remotely. Remote support is opt-in, to
-enable it you need to make sure that `devtools` is included in the repackaged archive:
+use several features when running applications remotely. Remote support is opt-in. To
+enable it, you need to make sure that `devtools` is included in the repackaged archive, as
+shown in the following listing:
 
 [source,xml,indent=0,subs="verbatim,quotes,attributes"]
 ----
@@ -969,7 +981,8 @@ enable it you need to make sure that `devtools` is included in the repackaged ar
 	</build>
 ----
 
-Then you need to set a `spring.devtools.remote.secret` property, for example:
+Then you need to set a `spring.devtools.remote.secret` property, as shown in the following
+example:
 
 [source,properties,indent=0]
 ----
@@ -979,21 +992,21 @@ Then you need to set a `spring.devtools.remote.secret` property, for example:
 WARNING: Enabling `spring-boot-devtools` on a remote application is a security risk. You
 should never enable support on a production deployment.
 
-Remote devtools support is provided in two parts; there is a server side endpoint that
-accepts connections, and a client application that you run in your IDE. The server
-component is automatically enabled when the `spring.devtools.remote.secret` property
-is set. The client component must be launched manually.
+Remote devtools support is provided in two parts: a server-side endpoint that accepts
+connections and a client application that you run in your IDE. The server component is
+automatically enabled when the `spring.devtools.remote.secret` property is set. The client
+component must be launched manually.
 
 
 
-==== Running the remote client application
+==== Running the Remote Client Application
 The remote client application is designed to be run from within your IDE. You need to run
-`org.springframework.boot.devtools.RemoteSpringApplication` using the same classpath as
-the remote project that you're connecting to. The _non-option_ argument passed to the
-application should be the remote URL that you are connecting to.
+`org.springframework.boot.devtools.RemoteSpringApplication` with the same classpath as
+the remote project that you connect to. The application's single required argument is the
+remote URL to which it connects.
 
-For example, if you are using Eclipse or STS, and you have a project named `my-app` that
-you've deployed to Cloud Foundry, you would do the following:
+For example, if you are using Eclipse or STS and you have a project named `my-app` that
+you have deployed to Cloud Foundry, you would do the following:
 
 * Select `Run Configurations...` from the `Run` menu.
 * Create a new `Java Application` "`launch configuration`".
@@ -1002,7 +1015,7 @@ you've deployed to Cloud Foundry, you would do the following:
 * Add `+++https://myapp.cfapps.io+++` to the `Program arguments` (or whatever your remote
   URL is).
 
-A running remote client will look like this:
+A running remote client might resemble the following listing:
 
 [indent=0,subs="attributes"]
 ----
@@ -1025,8 +1038,8 @@ NOTE: Because the remote client is using the same classpath as the real applicat
 can directly read application properties. This is how the `spring.devtools.remote.secret`
 property is read and passed to the server for authentication.
 
-TIP: It's always advisable to use `https://` as the connection protocol so that traffic is
-encrypted and passwords cannot be intercepted.
+TIP: It is always advisable to use `https://` as the connection protocol, so that traffic
+is encrypted and passwords cannot be intercepted.
 
 TIP: If you need to use a proxy to access the remote application, configure the
 `spring.devtools.remote.proxy.host` and `spring.devtools.remote.proxy.port` properties.
@@ -1034,35 +1047,33 @@ TIP: If you need to use a proxy to access the remote application, configure the
 
 
 [[using-boot-devtools-remote-update]]
-==== Remote update
-The remote client will monitor your application classpath for changes in the same way as
-the <<using-boot-devtools-restart,local restart>>. Any updated resource will be pushed
-to the remote application and _(if required)_ trigger a restart. This can be quite helpful
-if you are iterating on a feature that uses a cloud service that you don't have locally.
-Generally remote updates and restarts are much quicker than a full rebuild and deploy
-cycle.
+==== Remote Update
+The remote client monitors your application classpath for changes in the same way as the
+<<using-boot-devtools-restart,local restart>>. Any updated resource is pushed to the
+remote application and (_if required_) triggers a restart. This can be helpful if you
+iterate on a feature that uses a cloud service that you do not have locally. Generally,
+remote updates and restarts are much quicker than a full rebuild and deploy cycle.
 
 NOTE: Files are only monitored when the remote client is running. If you change a file
-before starting the remote client, it won't be pushed to the remote server.
+before starting the remote client, it is not pushed to the remote server.
 
 
 
 [[using-boot-packaging-for-production]]
-== Packaging your application for production
+== Packaging Your Application for Production
 Executable jars can be used for production deployment. As they are self-contained, they
 are also ideally suited for cloud-based deployment.
 
-For additional "`production ready`" features, such as health, auditing and metric REST
-or JMX end-points; consider adding `spring-boot-actuator`. See
+For additional "`production ready`" features, such as health, auditing, and metric REST
+or JMX end-points, consider adding `spring-boot-actuator`. See
 _<<production-ready-features.adoc#production-ready>>_ for details.
 
 
 
 [[using-boot-whats-next]]
-== What to read next
-You should now have good understanding of how you can use Spring Boot along with some best
-practices that you should follow. You can now go on to learn about specific
-_<<spring-boot-features#boot-features, Spring Boot features>>_ in depth, or you
-could skip ahead and read about the
-"`<<production-ready-features#production-ready, production ready>>`" aspects of Spring
-Boot.
+== What to Read Next
+You should now understand how you can use Spring Boot and some best practices that you
+should follow. You can now go on to learn about specific
+_<<spring-boot-features#boot-features, Spring Boot features>>_ in depth, or you could skip
+ahead and read about the "`<<production-ready-features#production-ready, production
+ready>>`" aspects of Spring Boot.