Correct the syntax that's used for smart single and double quotes

Fixes gh-1753

Author: wilkinsona

spring-boot-docs/src/main/asciidoc/appendix-auto-configuration-classes.adoc

@@ -10,15 +10,15 @@ application for more details of which features are switched on.
 
 
 [[auto-configuration-classes-from-autoconfigure-module]]
-=== From the ``spring-boot-autoconfigure'' module
+=== From the "`spring-boot-autoconfigure`" module
 The following auto-configuration classes are from the `spring-boot-autoconfigure` module:
 
 include::../../../target/generated-resources/auto-configuration-classes-spring-boot-autoconfigure.adoc[]
 
 
 
 [[auto-configuration-classes-from-actuator]]
-=== From the ``spring-boot-actuator'' module
+=== From the "`spring-boot-actuator`" module
 The following auto-configuration classes are from the `spring-boot-actuator` module:
 
 include::../../../target/generated-resources/auto-configuration-classes-spring-boot-actuator.adoc[]

spring-boot-docs/src/main/asciidoc/appendix-executable-jar-format.adoc

@@ -18,7 +18,7 @@ are themselves contained within a jar). This can be problematic if you are looki
 to distribute a self-contained application that you can just run from the command line
 without unpacking.
 
-To solve this problem, many developers use ``shaded'' jars. A shaded jar simply packages
+To solve this problem, many developers use "`shaded`" jars. A shaded jar simply packages
 all classes, from all jars, into a single 'uber jar'. The problem with shaded jars is
 that it becomes hard to see which libraries you are actually using in your application.
 It can also be problematic if the the same filename is used (but with different content)
@@ -91,7 +91,7 @@ a traditional web container should be placed in `WEB-INF/lib-provided`.
 
 
 [[executable-jar-jarfile]]
-=== Spring Boot's ``JarFile'' class
+=== Spring Boot's "`JarFile`" class
 The core class used to support loading nested jars is
 `org.springframework.boot.loader.jar.JarFile`. It allows  you load jar
 content from a standard jar file, or from nested child jar data. When first  loaded, the
@@ -121,7 +121,7 @@ need to read all entry data into memory.
 
 
 [[executable-jar-jarfile-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 `RandomAccessJarFile.getURL()` method will

spring-boot-docs/src/main/asciidoc/build-tool-plugins.adoc

@@ -7,7 +7,7 @@ Spring Boot provides build tool plugins for Maven and Gradle. The plugins offer
 variety of features, including the packaging of executable jars. This section provides
 more details on both plugins, as well as some help should you need to extend an
 unsupported build system. If you are just getting started, you might want to read
-``<<using-spring-boot.adoc#using-boot-build-systems>>'' from the
+"`<<using-spring-boot.adoc#using-boot-build-systems>>`" from the
 <<using-spring-boot.adoc#using-boot>> section first.
 --
 
@@ -17,7 +17,7 @@ unsupported build system. If you are just getting started, you might want to rea
 == Spring Boot Maven plugin
 The {spring-boot-maven-plugin-site}/[Spring Boot Maven Plugin] provides Spring Boot
 support in Maven, allowing you to package executable jar or war archives and run an
-application ``in-place''. To use it you must be using Maven 3 (or better).
+application "`in-place`". To use it you must be using Maven 3 (or better).
 
 NOTE: Refer to the {spring-boot-maven-plugin-site}/[Spring Boot Maven Plugin Site]
 for complete plugin documentation.
@@ -129,7 +129,7 @@ To build and run a project artifact, you can type the following:
 ----
 
 To build a war file that is both executable and deployable into an external container you
-need to mark the embedded container dependencies as ``provided'', e.g:
+need to mark the embedded container dependencies as "`provided`", e.g:
 
 [source,xml,indent=0,subs="verbatim,attributes"]
 ----
@@ -163,7 +163,7 @@ Advanced configuration options and examples are available in the
 == Spring Boot Gradle plugin
 The Spring Boot Gradle Plugin provides Spring Boot support in Gradle, allowing you to
 package executable jar or war archives, run Spring Boot applications and omit version
-information from your `build.gradle` file for ``blessed'' dependencies.
+information from your `build.gradle` file for "`blessed`" dependencies.
 
 
 
@@ -201,7 +201,7 @@ If you are using a milestone or snapshot release you will also need to add appro
 [[build-tool-plugins-gradle-dependencies-without-versions]]
 === Declaring dependencies without versions
 The `spring-boot` plugin will register a custom Gradle `ResolutionStrategy` with your
-build that allows you to omit version numbers when declaring dependencies to ``blessed''
+build that allows you to omit version numbers when declaring dependencies to "`blessed`"
 artifacts. To make use of this functionality, simply declare dependencies in the usual way,
 but leave the version number empty:
 
@@ -215,7 +215,7 @@ but leave the version number empty:
 ----
 
 NOTE: The version of the `spring-boot` gradle plugin that you declare determines the
-actual versions of the ``blessed'' dependencies (this ensures that builds are always
+actual versions of the "`blessed`" dependencies (this ensures that builds are always
 repeatable). You should always set the version of the `spring-boot` gradle plugin to the
 actual Spring Boot version that you wish to use. Details of the versions that are
 provided can be found in the <<appendix-dependency-versions, appendix>>.
@@ -237,7 +237,7 @@ example:
 [[build-tool-plugins-gradle-custom-version-management]]
 ==== Custom version management
 If is possible to customize the versions used by the `ResolutionStrategy` if you need
-to deviate from Spring Boot's ``blessed'' dependencies. Alternative version metadata
+to deviate from Spring Boot's "`blessed`" dependencies. Alternative version metadata
 is consulted using the `versionManagement` configuration. For example:
 
 [source,groovy,indent=0,subs="verbatim,attributes"]
@@ -263,7 +263,7 @@ to override version numbers if necessary.
 
 [[build-tool-plugins-gradle-exclude-rules]]
 === Default exclude rules
-Gradle handles ``exclude rules'' in a slightly different way to Maven which can cause
+Gradle handles "`exclude rules`" in a slightly different way to Maven which can cause
 unexpected results when using the starter POMs. Specifically, exclusions declared on
 a dependency will not be applied when the dependency can be reached through a different
 path. For example, if a starter POM declares the following:
@@ -296,7 +296,7 @@ which does not have an `exclusion` element.
 
 To ensure that correct exclusions are actually applied, the Spring Boot Gradle plugin will
 automatically add exclusion rules. All exclusions defined in the
-`spring-boot-dependencies` POM and implicit rules for the ``starter'' POMs will be added.
+`spring-boot-dependencies` POM and implicit rules for the "`starter`" POMs will be added.
 
 If you don't want exclusion rules automatically applied you can use the following
 configuration:
@@ -331,7 +331,7 @@ To build and run a project artifact, you can type the following:
 
 To build a war file that is both executable and deployable into an external container,
 you need to mark the embedded container dependencies as belonging to a configuration
-named ``providedRuntime'', e.g:
+named "`providedRuntime`", e.g:
 
 [source,groovy,indent=0,subs="verbatim,attributes"]
 ----
@@ -362,7 +362,7 @@ named ``providedRuntime'', e.g:
 
 [[build-tool-plugins-gradle-running-applications]]
 === Running a project in-place
-To run a project in place without building a jar first you can use the ``bootRun'' task:
+To run a project in place without building a jar first you can use the "`bootRun`" task:
 
 [indent=0]
 ----
@@ -513,7 +513,7 @@ The following configuration options are available:
  (defaults to a guess based on the archive type).
 
 |`requiresUnpack`
-|A list of dependencies (in the form ``groupId:artifactId'' that must be unpacked from
+|A list of dependencies (in the form "`groupId:artifactId`" that must be unpacked from
  fat jars in order to run. Items are still packaged into the fat jar, but they will be
  automatically unpacked when it runs.
 |===
@@ -573,7 +573,7 @@ you may find that it includes unnecessary dependencies.
 If you want to use a build tool other than Maven or Gradle, you will likely need to develop
 your own plugin. Executable jars need to follow a specific format and certain entries need
 to be written in an uncompressed form (see the
-'<<appendix-executable-jar-format.adoc#executable-jar, executable jar format>>' section
+_<<appendix-executable-jar-format.adoc#executable-jar, executable jar format>>_ section
 in the appendix for details).
 
 The Spring Boot Maven and Gradle plugins both make use of `spring-boot-loader-tools` to
@@ -637,4 +637,4 @@ technical details of the <<appendix-executable-jar-format.adoc#executable-jar, e
 jar format>> are covered in the appendix.
 
 If you have specific build-related questions you can check out the
-`<<howto.adoc#howto, how-to>>' guides.
+"`<<howto.adoc#howto, how-to>>`" guides.

spring-boot-docs/src/main/asciidoc/cloud-deployment.adoc

@@ -5,11 +5,11 @@
 --
 Spring Boot's executable jars are ready-made for most popular cloud PaaS
 (platform-as-a-service) providers. These providers tend to require that you
-_`bring your own container'_; they manage application processes (not Java applications
+"`bring your own container`"; they manage application processes (not Java applications
 specifically), so they need some intermediary layer that adapts _your_ application to the
 _cloud's_ notion of a running process.
 
-Two popular cloud providers, Heroku and Cloud Foundry, employ a ``buildpack'' approach.
+Two popular cloud providers, Heroku and Cloud Foundry, employ a "`buildpack`" approach.
 The buildpack wraps your deployed code in whatever is needed to _start_ your
 application: it might be a JDK and a call to `java`, it might be an embedded webserver,
 or it might be a full-fledged application server. A buildpack is pluggable, but ideally
@@ -22,7 +22,7 @@ to run packaged within it.
 
 In this section we'll look at what it takes to get the
 <<getting-started.adoc#getting-started-first-application, simple application that we
-developed>> in the ``Getting Started'' section up and running in the Cloud.
+developed>> in the "`Getting Started`" section up and running in the Cloud.
 --
 
 
@@ -226,7 +226,7 @@ Your application should now be up and running on Heroku.
 
 [[cloud-deployment-cloudbees]]
 == CloudBees
-CloudBees provides cloud-based ``continuous integration'' and ``continuous delivery''
+CloudBees provides cloud-based "`continuous integration`" and "`continuous delivery`"
 services as well as Java PaaS hosting. https://github.com/msgilligan[Sean Gilligan]
 has contributed an excellent
 https://github.com/CloudBees-community/springboot-gradle-cloudbees-sample[Spring Boot
@@ -308,9 +308,9 @@ features that a PaaS can offer. These are just three of the most popular Java Pa
 providers, since Spring Boot is so amenable to cloud-based deployment you're free to
 consider other providers as well.
 
-The next section goes on to cover the '<<spring-boot-cli.adoc#cli, Spring Boot CLI>>';
+The next section goes on to cover the _<<spring-boot-cli.adoc#cli, Spring Boot CLI>>_;
 or you can jump ahead to read about
-'<<build-tool-plugins.adoc#build-tool-plugins, build tool plugins>>'.
+_<<build-tool-plugins.adoc#build-tool-plugins, build tool plugins>>_.