anchor.diff:  
   The asset declaration should look like:
   
  -[source, json]
  -----
  -{
  -   "bundle" : "my-bundle",
  -   "assets": [{
  -      "locations": {
  -         "webapp": "/assets/js/application.js"
  -      }
  -   }]
  +.dandelion/bundle.json
  +[source, json]
  +----
  +{
  +  "assets": [
  +    {
  +      "locations": {
  +        "webapp": "/assets/js/application.js"
  +      }
  +    }
  +  ]
   }
   ----
   
  
positive.code:    }
  
     @Override
     protected String doGetContent(String location, Map&lt;String, Object> parameters, HttpServletRequest request) {
        return "the content of the asset";
     }
  }
  </pre>   
     </li>
     <li>
        <p>
           In the <code>META-INF/services</code> folder, create a text file (UTF-8 encoded) using the following convention:
  <pre class="prettyprint">
  yourJar
  |__ src
     |__ main
        |__ resources
           |__ META-INF
              |__ services
                 |__ com.github.dandelion.core.asset.locator.spi.AssetLocator
     
  </pre>   
        </p>
        <p>
           Inside this file, just add the fully qualified name of your own implementation. For example:
  <pre class="prettyprint">
  com.foo.asset.locator.impl.MyLocator
  </pre>
        </p>   
     </li>
  </ol>
  <p>
     And that's all! Dandelion, thanks to the SPI mechanism, will automatically pick up your
     implementation on the next restart.
  </p>
negative.code: == 5. Asset locators
  
  Assets can be fetched from different location thanks to _asset locators_. This section describes how it works and the available _asset locators_.
  
  === 5.1. Introducing asset locators
  
  An _asset locator_ (or _locator_ to simplify the language) is defined as follows:
  
  * A location key, used as an identifier in the bundle definitions
  * An associated location that may be processed, depending on the locator
  * A flag indicating whether the asset should be cached or not
  
  === 5.2 Asset caching
  
  Depending on the locator, Dandelion generates the right URL to serve the asset directly from the location where it lives. 
  
  For example, all assets present in the webapp directory are defaultly served by the webapp itself. In this case, Dandelion will just process the given location by prepending the context path and no caching is necessary.
  
  However, an asset stored in the classpath for example, cannot be served directly by the webapp. Instead, in such a case, Dandelion fetches its content and stores it in the configured <<9-asset-caching, cache system>>, with a particular cache key. Later, the generated link pointing to this asset will be served by the `DandelionServlet`, the role of which is to retrieve the content from the cache system and serve it.
  
  See the <<9-asset-caching, asset caching section>> for more information.
  
  === 5.3. Locations resolution strategy
  
  The most obvious case is to configure an asset with a single location.
  
  .jquery.json
  [source, json]
  ----
  {
    "assets": [
      {
        "locations": {
          "remote": "//cdnjs.cloudflare.com/ajax/libs/jquery/1.11.0/jquery.js",
        }
      }
    ]
  }
  ----
  
  In the above bundle, Dandelion will always use the single `remote` location to fetch the jQuery asset.
  
  In cases where multiple locations are configured for a single asset, Dandelion uses a particular strategy to resolve them. It simply reads the <<opt-asset.locations.resolution.strategy, `asset.locations.resolution.strategy`>> option from your configuration file and tests the specified locators in the given order.
  
  The default resolution strategy is defined as follows:
  
   asset.locations.resolution.strategy = webapp, webjar, jar, remote
  
  Here is what happens:
  
  . First checks if a `webapp` location key is specified. If so, the corresponding location will be selected and processed
  . Then, if a `webjar` location key is defined, the corresponding location will be selected and processed
  . Then, the same a `jar` location key
  . And finally with a `remote` location key
  . If none of the above is specified, an exception will be thrown.
  
  Assuming the following bundle:
  
  .jquery.json
  [source, json]
  ----
  {
    "assets": [
      {
        "locations": {
          "webapp" : "/assets/js/jquery.js",
          "remote": "//cdnjs.cloudflare.com/ajax/libs/jquery/1.11.0/jquery.js",
        }
      }
    ]
  }
  ----
  
  In such a case, thanks to the default resolution strategy, Dandelion will first prioritize the `webapp` location.
  
  TIP: Combined with <<10-profiles, profiles>>, this feature is powerful enough to handle multiple locations in multiple environments.
  
  === 5.4. Built-in locators
  
  Dandelion comes with a couple of built-in locators. They are all listed below.
  
  ==== 5.4.1. `webapp` locator
  
  The `webapp` locator should be used whenever you need to load an asset stored in the web application directory.
  
  |===
  | *Location key* | `webapp`
  
  | *Corresponding value* | Relative path to the web application root directory
  
  | *Caching forced* | No
  |===
  
  [discrete]
  ==== Example
  
  Assuming the following project structure:
  
  .Example with a Maven project
  [source, xml]
  ----
  your-project
  