anchor.diff:  
   The Groovy distribution comes with **two** jars:
   
  -- groovy-x.y.z.jar : makes use of call site caching
  -- groovy-x-y-z-indy.jar : has invokedynamic support bundled, old call site caching still possible
  +- groovy-x.y.z.jar : contains Groovy sources compiled with call site caching
  +- groovy-x-y-z-indy.jar : contains Groovy sources compiled with invokedynamic instructions
   
  -The first jar is Groovy compiled without invokedynamic support, while the second one has invokedynamic support bundled. As Groovy core and the groovy modules are sometimes written in Groovy, we currently have no choice but issuing two distinct versions of Groovy. This means that if you pick the "normal" jar, the groovy classes of groovy itself are compiled with call site caching (1.5+), while if you use the "indy" jar, the groovy classes of groovy itself are compiled using invokedynamic. This means that the invokedynamic version of Groovy doesn't make use of the old call site caching mechanism.
  +As Groovy core and the Groovy modules are sometimes written in Groovy, we currently have no choice but to distribute two
  +distinct versions of Groovy. This means that if you pick the "normal" jar, the Groovy classes of Groovy itself are
  +compiled with call site caching (1.6+), while if you use the "indy" jar, the Groovy classes of Groovy itself are
  +compiled using invokedynamic.
   
  -Both jars contain a fully working groovy implementation. They are mutually exclusive (don't put both on classpath).
  +Both jars contain a fully working Groovy implementation that is capable of compiling user supplied Groovy sources using either
  +invokedynamic or call site caching. The sets of jars are mutually exclusive (don't put both on classpath) and the key difference between
  +them has to do with how the Groovy source files that make up Groovy itself are compiled.
   
   === Command-line and indy
  -If you download the distribution and that you use the command line, it's always the "normal" version of Groovy which is picked up in classpath. This means that whatever command you use (`groovy`, `groovyc`, `groovysh` or `groovyConsole`), invokedynamic support is not available out of the box. To use the invokedynamic version, you have to switch the jars manually. The distribution makes use of the jars in the ++lib++ directory, while the indy jars are available in the ++indy++ directory. You have three things to do:
  +If you download the distribution and use the command line, it's always the "normal" version of Groovy which is picked up in classpath. This means that whatever command you use (`groovy`, `groovyc`, `groovysh` or `groovyConsole`), invokedynamic support is not available out of the box. To use a Groovy distribution that was compiled with invokedynamic for its Groovy sources you have to switch the jars manually. The distribution makes use of the jars in the ++lib++ directory, while the indy jars are available in the ++indy++ directory. You have three things to do:
   
   - remove or rename the groovy-*.jar files in the lib directory
   - replace them with the indy version from the indy directory
  
positive.code: 
  |normal jar
  |call site caching
  |N/A
  
  |indy jar
  |invokedynamic
  
negative.code: $ for f in `ls lib/groovy*.jar | cut -d/ -f2`;do k=`basename $f .jar`; mv lib/$k.jar lib/$k.jar.old; cp indy/$k-indy.jar lib/$k.jar ; done
  ----
  
  == Running groovy script from command line
  
  The usual way to run a script from the command line is by `groovy foo.groovy`, where `foo.groovy` is the Groovy program
  in source form. To use indy for this you have to use the indy compilation flag, `groovy --indy foo.groovy`.
  
  == The compilation flag
  
  Independently of the jar version that you use (and after having exchanged the jars as described), invokedynamic support requires a specific compilation flag (__indy__). If you want to compile your classes with invokedynamic support, this flag must be set at compile time. The following tables show you what happens with user compiled classes and Groovy core classes depending on the jar you use and the compilation flag:
  
  [cols="1,1,1" options="header"]
  .user compiled classes
  