anchor.diff:  ----
   
   The configuration file describes how the jar can be separated into layers, and the order of those layers.
  -The following example shows how the default ordering described above can be defined explicity:
  +The following example shows how the default ordering described above can be defined explicitly:
   
   [source,xml,indent=0,subs="verbatim,attributes"]
   ----
  
positive.code: [[repackage-layers]]
  === Layered jars
  A repackaged jar contains the application's classes and dependencies in `BOOT-INF/classes` and `BOOT-INF/lib` respectively.
  For cases where a docker image needs to be built from the contents of the jar, it's useful to be able to separate these folders futher so that they can be written into distinct layers.
  
  Layered jars use the same layout as regular repackaged jars, but include an additional meta-data file that describes each layer.
  To use this feature, the layering feature must be enabled:
  
negative.code: 
  Nested `<into>` blocks are used within `<application>` and `<dependencies>` sections to claim content for a layer.
  The blocks are evaluated in the order that they are defined, from top to bottom.
  Any content not claimed by an earlier block remains available for subsequent blocks to consider.
  
  The `<into>` block claims content using nested `<include>` and `<exclude>` elements.
  The `<application>` section uses Ant-style patch matching for include/exclude expressions.
  The `<dependencies>` section uses `group:artifact[:version]` patterns.
  
  If no `<include>` is defined, then all content (not claimed by an earlier block) is considered.
  