anchor.diff:  	}
   ----
   
  -NOTE: `providedRuntime` is preferred to Gradle's `compileOnly` configuration as, among other
  +NOTE: `providedRuntime` is preferred to Gradle's `compileOnly` configuration. Among other
   limitations, `compileOnly` dependencies are not on the test classpath so any web-based
  -integration tests will fail.
  -
  -If you're using the <<build-tool-plugins.adoc#build-tool-plugins, Spring Boot build tools>>,
  -marking the embedded servlet container dependency as provided will produce an executable war
  +integration tests fail.
  +
  +If you use the <<build-tool-plugins.adoc#build-tool-plugins, Spring Boot build tools>>,
  +marking the embedded servlet container dependency as provided produces an executable war
   file with the provided dependencies packaged in a `lib-provided` directory. This means
   that, in addition to being deployable to a servlet container, you can also run your
  -application using `java -jar` on the command line.
  +application by using `java -jar` on the command line.
   
   TIP: Take a look at Spring Boot's sample applications for a
   {github-code}/spring-boot-samples/spring-boot-sample-traditional/pom.xml[Maven-based example]
  -of the above-described configuration.
  +of the previously described configuration.
   
   
   
   [[howto-create-a-deployable-war-file-for-older-containers]]
  -=== Create a deployable war file for older servlet containers
  -Older Servlet containers don't have support for the `ServletContextInitializer` bootstrap
  +=== Create a Deployable War File for Older Servlet Containers
  +Older Servlet containers do not have support for the `ServletContextInitializer` bootstrap
   process used in Servlet 3.0. You can still use Spring and Spring Boot in these containers
   but you are going to need to add a `web.xml` to your application and configure it to load
   an `ApplicationContext` via a `DispatcherServlet`.
  
positive.code: 	app.datasource.bar.max-total=30
  ----
  
  Of course, you can apply the same concept to the secondary `DataSource` as well:
  
  [source,java,indent=0,subs="verbatim,quotes,attributes"]
  ----
  include::{code-examples}/jdbc/CompleteTwoDataSourcesExample.java[tag=configuration]
  ----
  
  This final example configures two data sources on custom namespaces with the same logic
  as what Spring Boot would do in auto-configuration.
  
  
  
  [[howto-use-spring-data-repositories]]
  === Use Spring Data repositories
  Spring Data can create implementations for you of `@Repository` interfaces of various
  flavors. Spring Boot will handle all of that for you as long as those `@Repositories`
  are included in the same package (or a sub-package) of your `@EnableAutoConfiguration`
  class.
  
  For many applications all you will need is to put the right Spring Data dependencies on
  your classpath (there is a `spring-boot-starter-data-jpa` for JPA and a
  `spring-boot-starter-data-mongodb` for Mongodb), create some repository interfaces to handle your
  `@Entity` objects. Examples are in the {github-code}/spring-boot-samples/spring-boot-sample-data-jpa[JPA sample]
  or the {github-code}/spring-boot-samples/spring-boot-sample-data-mongodb[Mongodb sample].
  
  Spring Boot tries to guess the location of your `@Repository` definitions, based on the
  `@EnableAutoConfiguration` it finds. To get more control, use the `@EnableJpaRepositories`
  
negative.code: 		port: 9000
  ----
  
  Create a file called `application.yml` and put it in the root of your classpath.
  Then add `snakeyaml` to your dependencies (Maven coordinates `org.yaml:snakeyaml`, already
  included if you use the `spring-boot-starter`). A YAML file is parsed to a Java
  `Map<String,Object>` (like a JSON object), and Spring Boot flattens the map so that it
  is one level deep and has period-separated keys, as many people are used to with
  `Properties` files in Java.
  
  The example YAML above corresponds to an `application.properties` file as follows:
  
  [source,properties,indent=0,subs="verbatim,quotes,attributes"]
  ----
  