anchor.diff:  * Placeholder replacement is done from System and environment variables plus the
     properties file itself on all values before use.
   * The search order for properties (where it makes sense to look in more than one place)
  -  is env vars, system properties, `loader.properties`, exploded archive manifest, archive
  -  manifest.
  +  is environment variables, system properties, `loader.properties`, the exploded archive
  +	manifest, and the archive manifest.
   
   
   
   [[executable-jar-restrictions]]
  -=== Executable jar restrictions
  -There are a number of restrictions that you need to consider when working with a Spring
  -Boot Loader packaged application.
  +=== Executable Jar Restrictions
  +You need to consider the following restrictions when working with a Spring
  +Boot Loader packaged application:
   
   
   
   [[executable-jar-zip-entry-compression]]
  -==== Zip entry compression
  -The `ZipEntry` for a nested jar must be saved using the `ZipEntry.STORED` method. This
  +* Zip entry compression:
  +The `ZipEntry` for a nested jar must be saved by using the `ZipEntry.STORED` method. This
   is required so that we can seek directly to individual content within the nested jar.
   The content of the nested jar file itself can still be compressed, as can any other
   entries in the outer jar.
  
positive.code: [appendix]
  [[executable-jar]]
  == The executable jar format
  The `spring-boot-loader` modules allows Spring Boot to support executable jar and
  war files. If you're using the Maven or Gradle plugin, executable jars are
  automatically generated and you generally won't need to know the details of how
  they work.
  
  If you need to create executable jars from a different build system, or if you are just
  curious about the underlying technology, this section provides some background.
  
  
  
  [[executable-jar-nested-jars]]
  === Nested JARs
  Java does not provide any standard way to load nested jar files (i.e. jar files that
  are themselves contained within a jar). This can be problematic if you are looking
  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
  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 same filename is used (but with different content)
  in multiple jars. Spring Boot takes a different approach and allows you to actually nest
  jars directly.
  
  
  
  [[executable-jar-jar-file-structure]]
  ==== The executable jar file structure
  Spring Boot Loader compatible jar files should be structured in the following way:
  
  [indent=0]
  ----
  
negative.code: 	Start-Class: com.mycompany.project.MyApplication
  ----
  
  For a war file, it would be as follows:
  
  [indent=0]
  ----
  