anchor.diff:  
   ~~~
   
  -Note that cf CLI displays the returned STDOUT "framework name" when printing the details of an application. Buildpack authors are therefore encouraged to include additional details in this returned framework name, such as buildpack versioning information, and a detailed list of configured frameworks and their associated versions. The following is an example of the detailed information returned by the Java buildpack:
  +Optionally, the buildpack detect script can output additional details decided by the buildpack developer. Such as buildpack versioning information, a detailed list of configured frameworks and their associated versions. The following is an example of the detailed information returned by the Java buildpack:
   
   ~~~
   java-buildpack=v3.0-https://github.com/cloudfoundry/java-buildpack.git#3bd15e1 open-jdk-jre=1.8.0_45 spring-auto-reconfiguration=1.7.0_RELEASE tomcat-access-logging-support=2.4.0_RELEASE tomcat-instance=8.0.21 tomcat-lifecycle-support=2.4.0_RELEASE ...
  
positive.code: end
  
  ~~~
  
  ### <a id='release-script'></a>bin/release ###
  
  The `release` script provides feedback metadata back to Cloud Foundry indicating how the application should be executed. The script is run with one argument, the build location of the application. The script must generate a YAML file in the following format:
  
negative.code: 
  ### <a id='compile-script'></a>bin/compile ###
  
  The `compile` script builds a droplet by packaging the application's dependencies, assuring that the application has all the necessary components needed to run.
  
  The script is run with two arguments, the build directory for the application and the cache directory, which is a location the buildpack can use to store assets during the build process.
  
  