anchor.diff:  #### Manifest Attributes
   The `docker` attribute cannot be used in conjunction with the following attributes: `buildpack` and `path`. An error will result.
   
  -###<a id='domain'></a>domain ###
  -
  -Every `cf push` deploys applications to one particular Cloud Foundry instance.
  -Every Cloud Foundry instance may have a shared domain set by an admin.
  -Unless you specify a domain, Cloud Foundry incorporates that shared domain in the route to your application.
  -
  -You can use the `domain` attribute when you want your application to be served from a domain other than the default shared domain.
  -
  -<pre>
  ----
  -  ...
  -  domain: unique-example.com
  -</pre>
  -
  -The command line option that overrides this attribute is `-d`.
  -
  -###<a id='domains'></a>domains ###
  -
  -Use the `domains` attribute to provide multiple domains. If you define both `domain` and `domains` attributes, Cloud Foundry creates routes for domains defined in both of these fields.
  -
  -<pre>
  ----
  -  ...
  -  domains:
  -  - domain-example1.com
  -  - domain-example2.org
  -</pre>
  -
  -The command line option that overrides this attribute is `-d`.
  -
   ###<a id='health-check-http-endpoint'></a>health-check-http-endpoint ###
   
   Use the `health-check-http-endpoint` attribute to customize the endpoint for the `http` health check type. If you do not provide a `health-check-http-endpoint` attribute, 
  
positive.code: 
  ##<a id='minimize-duplication'></a>Minimizing Duplication ##
  
  In manifests where multiple applications share settings or services, you begin to see content duplicated. While the manifests still work, duplication increases the risk of typographical errors which cause deployment to fail.
  
  The cure for this problem is to "promote" the duplicate content—that is, to move it up above the applications block, where it need appear only once. The promoted content applies to all applications described in the manifest. Note that content _in_ the applications block overrides content _above_ the applications block, if the two conflict.
  
  The manifest becomes shorter, more readable, and more maintainable.
  
  Notice how much content in the manifest below has been promoted in this way.
  
  <pre>
  ---
    ...
  # all applications use these settings and services
  domain: <%=vars.app_domain%>
  memory: 1G
  instances: 1
  services:
  - clockwork-mysql
  applications:
  - name: springtock
    host: tock09876
    path: ./spring-music/build/libs/spring-music.war
  - name: springtick
    host: tick09875
    path: ./spring-music/build/libs/spring-music.war
  </pre>
  
  In the next section we carry this principle further by distributing content across multiple manifests.
  
  ##<a id='multi-manifests'></a>Multiple Manifests with Inheritance ##
  
  
negative.code: </pre>
  
  <p class='note'><strong>Note</strong>: Inheritance can add an additional level of complexity to manifest creation and maintenance. Comments that precisely explain how the child manifest extends or overrides the descriptions in the parent manifest can alleviate this complexity.</p>
  
  ## <a id=‘deprecated’></a> Deprecated App Manifest Features
  
  These app manifest features have been deprecated in favor of existing options.
  
  ### <a id=‘yaml-anchors’></a> YAML Anchors Replace Promoted Content
  
  Previously, you could manage duplicated settings in YAML files by “promoting” the duplicate content — that is, by moving it to above the applications block, where it need appear only once.
  
  The following example illustrates how promoted content was used to manage duplicated settings.
  
  <pre>
    ...
  # all applications use these settings and services
  domain: shared-domain.example.com
  memory: 1G
  instances: 1
  services:
  - clockwork-mysql
  applications:
  - name: springtock
    host: tock09876
    path: ./spring-music/build/libs/spring-music.war
  - name: springtick
    host: tick09875
    path: ./spring-music/build/libs/spring-music.war
  </pre>
  
  Now, you can use YAML aliases instead.
              
  The following example illustrates how to declare shared configuration using a YAML anchor, which the manifest refers to in app declarations by using an alias.
  
  <pre>
  defaults: &amp;defaults
    buildpack: staticfile_buildpack
    memory: 1&nbsp;G
  
  applications:
  - name: bigapp
    &lt;&lt;: defaults
  - name: smallapp
    &lt;&lt;: defaults
    memory: 256&nbsp;M
  </pre>
  
  When pushing the app, make explicit the attributes in each app’s declaration. To do this, assign the anchors and include the app-level attributes with YAML aliases in each app declaration.
  
  ### <a id=‘route-attribute’></a> Attribute `routes` Replaces `domain`, `domains`, `host`, `hosts`, and `no-hostname`
  
  Previously, you could specify routes by listing them all at once using the `routes` attribute, or by using their host(s) and/or domain(s) as shown below.
  
  <pre>
  applications
  - name: webapp
    host: www
    domains:
    - example.com
    - example.io
  </pre>
  
  The route component attributes above are deprecated. Now you can only specify routes by using the `routes` attribute:
  
  <pre>
  applications
  - name: webapp
    routes:
    - route: www.example.com/foo 
    - route: tcp.example.com:1234
  </pre>