mguymon-buildr 1.4.5-java

data/doc/index.textile

@@ -0,0 +1,109 @@
+---
+layout: default
+title: Apache Buildr
+---
+
+Apache Buildr is a build system for Java-based applications, including support for Scala, Groovy and a growing number of JVM languages and tools.  We wanted something that's simple and intuitive to use, so we only need to tell it what to do, and it takes care of the rest.  But also something we can easily extend for those one-off tasks, with a language that's a joy to use.  And of course, we wanted it to be fast, reliable and have outstanding dependency management.
+
+
+h2(#why).  Why Buildr Rocks
+
+"Daniel Spiewak":http://www.codecommit.com/blog:
+
+bq. If you think about it, the question isn’t “Why use Buildr?”, it’s really “Why use anything else?” The advantages afforded by Buildr are so substantial, I really can’t see myself going with any other tool, at least not when I have a choice.
+
+"Tristan Juricek":http://tristanhunt.com/:
+
+bq. That’s still the strongest sell: it builds everything I need, and as I’ve needed more, I just got things working without a lot of fuss.
+
+"Matthieu Riou":http://offthelip.org/:
+
+bq. We used to rely on Ant, with a fairly extensive set of scripts. It worked but was expensive to maintain. The biggest mistake afterward was to migrate to Maven2. I could write pages of rants explaining all the problems we ran into and we still ended up with thousands of lines of XML.
+
+"Martin Grotzke":http://www.javakaffee.de/blog/:
+
+bq. The positive side effect for me as a java user is that I learn a little ruby, and that’s easy but lots of fun… :-)
+
+"Ijonas Kisselbach":http://twitter.com/ijonas/statuses/4134103928:
+
+bq. I've cleaned up & migrated the Vamosa build process from 768 lines of Ant build.xml to 28 lines of Buildr.
+
+h2(#what).  What You Get
+
+* A simple way to specify projects, and build large projects out of smaller sub-projects.
+* Pre-canned tasks that require the least amount of configuration, keeping the build script DRY and simple.
+* Compiling, copying and filtering resources, JUnit/TestNG test cases, APT source code generation, Javadoc and more.
+* A dependency mechanism that only builds what has changed since the last release.
+* A drop-in replacement for Maven 2.0, Buildr uses the same file layout, artifact specifications, local and remote repositories.
+* All your Ant tasks are belong to us! Anything you can do with Ant, you can do with Buildr.
+* No overhead for building "plugins" or configuration. Just write new tasks or functions.
+* Buildr is Ruby all the way down.  No one-off task is too demanding when you write code using variables, functions and objects.
+* Simple way to upgrade to new versions.
+* Did we mention fast?
+
+So let's get started.  You can "read the documentation online":quick_start.html, or "download the PDF":buildr.pdf.
+
+
+h2(#news).  What's New
+
+New in Buildr 1.4.5 (Feb. 20th, 2011)
+
+* Added:  BUILDR-555 Add support for the jaxb binding compiler (Mark Petrovic)
+* Added:  BUILDR-554 Add support for OSGi bundle packages by importing the
+          buildr_bnd plugin
+* Added:  BUILDR-125 Add support for <security-role> in application.xml of
+          EAR packaging (Mikael Amborn)
+* Added:  BUILDR-550 Add support for groovydoc
+* Added:  BUILDR-521: System tray notifications for Linux systems
+          (via libnotify/notify-send)
+* Added:  BUILDR-537 Shell tasks should use JAVA_OPTS by default
+* Added:  BUILDR-538 Shell tasks should support passing :java_args
+* Added:  BUILDR-544 Support ${groupId} in pom files (Chris Dean)
+* Added:  BUILDR-552 Projects may now be defined using project(:name) and a block
+* Added:  BUILDR-564 Add package(:scaladoc)
+* Added:  Automatically add "require buildr/{groovy,scala}"  when generating
+          project if Groovy/Scala files are detected.
+* Change: BUILDR-540 Upgrade to rspec 2.1.0
+* Change: BUILDR-546 Upgrade to Rubyzip 0.9.4 (Michael Guymon)
+* Change: BUILDR-556 Merge buildr-iidea extension back into buildr.
+* Change: Upgrade default Scala compiler version to 2.8.1-final
+* Change: Upgrade to ScalaCheck 1.8
+* Change: Upgrade to ScalaTest 1.3
+* Change: Upgrade to Specs 1.6.6
+* Change: Upgrade to JRuby 1.5.6
+* Fixed:  BUILDR-542 Release task:  SVN tagging fails if parent tag directory
+          does not exist yet (Gerolf Seitz)
+* Fixed:  BUILDR-543 POMs are installed and uploaded twice when using artifacts
+          with classifier
+* Fixed:  BUILDR-522 Send notifications when continuous compilation
+          succeeds/fails.
+* Fixed:  BUILDR-551 Continuous compilation not working for project trees
+* Fixed:  BUILDR-557 MD5 + SHA1 checksums are not Maven compliant (Tammo van Lessen)
+* Change: Upgrade to Groovy 1.7.5
+* Change: BUILDR-545 Add the ability to specify the description element in in
+          application.xml contained within an ear.
+* Fixed:  BUILDR-547 - Ensure ECJ compiler works when there is a space in the
+          path of dependencies.
+* Fixed:  BUILDR-558 Artifact uploads should show a progress bar (Tammo van Lessen)
+* Fixed:  BUILDR-560 show a meaning full error message when POM cannot be parsed
+          (Tammo van Lessen)
+* Fixed:  BUILDR-562 WAR package isn't updated if files under src/main/webapp
+          are updated
+* Fixed:  BUILDR-569 Buildr fails under JRuby 1.6.0.RC1 due to read-only $? variable
+* Fixed:  BUILDR-570 Buildr does not work with Rubygems 1.5.x
+* Fixed:  Scaladoc task would cause build to exit prematurely
+
+See the "CHANGELOG":CHANGELOG for full details.
+
+h2(#notices).  Credits & Notices
+
+!http://www.apache.org/images/asf-logo.gif(A project of the Apache Software Foundation)!:http://www.apache.org
+
+The Apache Software Foundation is a non-profit organization, consider "sponsoring":http://www.apache.org/foundation/sponsorship.html and check the "thanks":http://www.apache.org/foundation/thanks.html page.
+
+"ColorCons":http://www.mouserunner.com/Spheres_ColoCons1_Free_Icons.html, copyright of Ken Saunders.  "DejaVu fonts":http://dejavu.sourceforge.net, copyright of Bitstream, Inc.
+
+Community member quotes from a thread on "Stack Overflow":http://stackoverflow.com/questions/1015525/why-use-buildr-instead-of-ant-or-maven/1055864.
+
+Developed with !http://www.jetbrains.com/ruby/features/ruby_banners/ruby1/ruby120x30_white.gif(Developed with RubyMine)!:http://www.jetbrains.com/ruby/features?utm_source=RubyMineUser&utm_medium=Banner&utm_campaign=RubyMine
+

data/doc/installing.textile

@@ -0,0 +1,284 @@
+---
+layout: default
+title: Installing and Running
+---
+
+
+*The easy way:*  We recommend you pick the platform you want to run Buildr on and then follow the _easy way_ instructions for that platform.  It could save you an hour or two struggling to install all the right dependencies.
+
+"Installing Buildr for JRuby":#jruby is the same on all operating systems.  Choose JRuby if you're working with Java 6 on OS X, developing with multiple JDKs, or just like JRuby better.
+
+If you are running behind a proxy server, make sure the environment variable @HTTP_PROXY@ is set, as many of these steps require HTTP access.
+
+<br>
+
+*In details:* The @gem install@ and @gem update@ commands install Buildr from a binary distribution provided through "RubyForge":http://rubyforge.org/projects/buildr. This distribution is maintained by contributors to this project, but is *not* an official Apache distribution.  You can obtain the official Apache distribution files from the "download page":download.html.
+
+Older versions of RubyGems are all kind of fail.  You want to avoid these unless you have the patience to install each Buildr dependency manually.  Get RubyGems 1.3.1 or later, and when using Debian packages (e.g. Ubuntu), make sure to get the unmolested RubyGems straight form the source.
+
+The Ruby interpreter and JVM must use compatible architectures.  For example, OS X comes with 32-bit version of Ruby, Java 1.5 in both 32-bit and 64-bit flavors, and 64-bit Java 6.  As a result you can run Ruby with Java 1.5 (32-bit), but to use Java 6 you either need to build Ruby from source for 64-bit, or use "Buildr for JRuby":#jruby.
+
+h2(#linux).  Installing on Linux
+
+*The easy way:* Use this bash script to "install Buildr on Linux":scripts/install-linux.sh.  This script will install the most recent version of Buildr, or if already installed, upgrade to the most recent version.  It will also install Ruby 1.8.6 if not already installed (requires @apt-get@, @yum@ or @urpmi@) and upgrade to RubyGems 1.3.1 or later.
+
+<br>
+
+*In details:* To get started you will need a recent version of Ruby, Ruby Gems and build tools for compiling native libraries (@make@, @gcc@ and standard headers).
+
+On *RedHat/Fedora* you can use yum to install Ruby and RubyGems, and then upgrade to the most recent version of RubyGems:
+
+{% highlight sh %}
+$ sudo yum install ruby rubygems ruby-devel gcc
+$ sudo gem update --system
+{% endhighlight %}
+
+On *Ubuntu* you have to install several packages:
+
+{% highlight sh %}
+$ sudo apt-get install ruby-full ruby1.8-dev libopenssl-ruby build-essential
+{% endhighlight %}
+
+If using Ubuntu 9.10 or earlier, the Debian package for @rubygems@ will not allow you to install Buildr, so you need to install RubyGems from source:
+
+{% highlight sh %}
+$ wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz
+$ tar xzf rubygems-1.3.1.tgz
+$ cd rubygems-1.3.1
+$ sudo ruby setup.rb
+$ sudo ln -s /usr/bin/gem1.8 /usr/bin/gem
+{% endhighlight %}
+
+Before installing Buildr, please set the @JAVA_HOME@ environment variable to point to your JDK distribution.  Next, use Ruby Gem to install Buildr:
+
+{% highlight sh %}
+$ sudo env JAVA_HOME=$JAVA_HOME gem install buildr
+{% endhighlight %}
+
+To upgrade to a new version or install a specific version:
+
+{% highlight sh %}
+$ sudo env JAVA_HOME=$JAVA_HOME gem update buildr
+$ sudo env JAVA_HOME=$JAVA_HOME gem install buildr -v 1.4.3
+{% endhighlight %}
+
+
+h2(#osx).  Installing on OS X
+
+*The easy way:* Use this script to "install Buildr on OS X":scripts/install-osx.sh.  This script will install the most recent version of Buildr, or if already installed, upgrade to the most recent version.  It will also install Ruby 1.8.6 if not already installed (using MacPorts/Fink) and upgrage RubyGems to 1.3.1 or later.
+
+You need to have the Apple Development Tools installed.  They are available on the Mac OSX installation CD.
+
+p(note). Java Update 3 for Snow Leopard removes header files necessary to compile the native Ruby-Java Bridge (RJB) gem, so installing rjb gem may fail on OS X.  The solution is to install Java for Mac OS X 10.6 Update 3 Developer Package from http://connect.apple.com before @gem install@.
+
+*Using RVM?* If you're not using the built-in ruby on OS X (e.g., if you're using RVM), you'll need to force-install the platform-independent RJB:
+
+{% highlight sh %}
+$ gem install rjb -v 1.3.3 --platform ruby
+{% endhighlight %}
+
+The darwin pre-built binary seems to only work with the built-in ruby.
+
+<br>
+
+*In details:* OS X 10.5 (Leopard) comes with a recent version of Ruby 1.8.6.  You do not need to install a different version of Ruby when running OS X 10.5.
+
+OS X 10.4 (Tiger) includes an older version of Ruby that is not compatible with Buildr.  You can install Ruby 1.8.6 using MacPorts (@sudo port install ruby rb-rubygems@), Fink or the "Ruby One-Click Installer for OS X":http://rubyosx.rubyforge.org/.
+
+We recommend you first upgrade to the latest version of Ruby gems:
+
+{% highlight sh %}
+$ sudo gem update --system
+{% endhighlight %}
+
+Before installing Buildr, please set the @JAVA_HOME@ environment variable to point to your JDK distribution:
+
+{% highlight sh %}
+$ export JAVA_HOME=/Library/Java/Home
+{% endhighlight %}
+
+To install Buildr:
+
+{% highlight sh %}
+$ sudo env JAVA_HOME=$JAVA_HOME gem install buildr
+{% endhighlight %}
+
+To upgrade to a new version or install a specific version:
+
+{% highlight sh %}
+$ sudo env JAVA_HOME=$JAVA_HOME gem update buildr
+$ sudo env JAVA_HOME=$JAVA_HOME gem install buildr -v 1.3.4
+{% endhighlight %}
+
+h2(#windows).  Installing on Windows
+
+*The easy way:*  The easiest way to install Ruby is using the "one-click installer":http://rubyinstaller.rubyforge.org/.  Be sure to install Ruby 1.8.6; support for Ruby 1.9.x is still a work in progress.  Once installed, set the @JAVA_HOME@ environment variable and run @gem install buildr --platform mswin32@.
+
+<br>
+
+*In details:* We recommend you first upgrade to the latest version of Ruby gems:
+
+{% highlight sh %}
+> gem update --system
+{% endhighlight %}
+
+Before installing Buildr, please set the @JAVA_HOME@ environment variable to point to your JDK distribution.  Next, use Ruby Gem to install Buildr:
+
+{% highlight sh %}
+> gem install buildr --platform mswin32
+{% endhighlight %}
+
+To upgrade to a new version or install a specific version:
+
+{% highlight sh %}
+> gem update buildr
+> gem install buildr -v 1.3.4 --platform mswin32
+{% endhighlight %}
+
+h2(#jruby).  Installing for JRuby
+
+*The easy way:* Use this bash script to "install Buildr on JRuby":scripts/install-jruby.sh.  This script will install the most recent version of Buildr, or if already installed, upgrade to the most recent version.  If necessary, it will also install JRuby 1.1.6 in @/opt/jruby@ and update the @PATH@ variable in @~/.bash_profile@ or @~/.profile@.
+
+<br>
+
+*In details:* If you don't already have JRuby 1.1.6 or later installed, you can download it from the "JRuby site":http://dist.codehaus.org/jruby/.
+
+After uncompressing JRuby, update your @PATH@ to include both @java@ and @jruby@ executables.
+
+For Linux and OS X:
+
+{% highlight sh %}
+$ export PATH=$PATH:[path to JRuby]/bin:$JAVA_HOME/bin
+$ jruby -S gem install buildr
+{% endhighlight %}
+
+For Windows:
+
+{% highlight sh %}
+> set PATH=%PATH%;[path to JRuby]/bin;%JAVA_HOME%/bin
+> jruby -S gem install buildr
+{% endhighlight %}
+
+To upgrade to a new version or install a specific version:
+
+{% highlight sh %}
+$ jruby -S gem update buildr
+$ jruby -S gem install buildr -v 1.3.4
+{% endhighlight %}
+
+
+*Important: Running JRuby and Ruby side by side*
+
+Ruby and JRuby maintain separate Gem repositories, and in fact install slightly different versions of the Buildr Gem (same functionality, different dependencies).  Installing Buildr for Ruby does not install it for JRuby and vice versa.
+
+If you have JRuby installed but not Ruby, the @gem@ and @buildr@ commands will use JRuby.  If you have both JRuby and Ruby installed, follow the instructions below.  To find out if you have Ruby installed (some operating systems include it by default), run @ruby --version@ from the command line.
+
+To work exclusively with JRuby, make sure it shows first on the path, for example, by setting @PATH=/opt/jruby/bin:$PATH@.
+
+You can use JRuby and Ruby side by side, by running scripts with the @-S@ command line argument.  For example:
+
+{% highlight sh %}
+$ # with Ruby
+$ ruby -S gem install buildr
+$ ruby -S buildr
+$ # with JRuby
+$ jruby -S gem install buildr
+$ jruby -S buildr
+{% endhighlight %}
+
+Run @buildr --version@ from the command line to find which version of Buildr you are using by default.  If you see @(JRuby ...)@, Buildr is running on that version of JRuby.
+
+h2. Using multiple versions of Buildr
+
+Rubygems makes it possible to install several versions of Buildr side-by-side on the same system.  If you want to run a specific version, you can do so by adding the version number between underscores ('_') as the first command-line parameter.  For example,
+
+{% highlight sh %}
+$ buildr _1.3.4_ clean   # runs Buildr v1.3.4
+
+$ buildr _1.4.4_ clean   # runs Buildr v1.4.4
+{% endhighlight %}
+
+p(note). There are two `buildr` executables installed by Rubygems.  One script serves to select the specified (or default) version of Buildr and is typically found under `/usr/bin/buildr` or `/var/lib/gems/1.8/bin/buildr`. The exact location will vary depending on your system.   The other script is the Buildr bootstrap per se and can be found under the specific version of Buildr, e.g, `/var/lib/gems/1.8/gems/buildr-1.4.0/bin/buildr`.   The first script should be on your `PATH`.   The second script should not be called directly and should not be on your `PATH`.
+
+h2(#running). Running Buildr
+
+You need a *Buildfile*, a build script that tells Buildr all about the projects it's building, what they contain, what to produce, and so on.  The Buildfile resides in the root directory of your project.  We'll talk more about it in "the next chapter":projects.html.  If you don't already have one, ask Buildr to create it by running @buildr@.
+
+p(tip). You'll notice that Buildr creates a file called @buildfile@.  It's case sensitive, but Buildr will look for either @buildfile@ or @Buildfile@.
+
+You use Buildr by running the @buildr@ command:
+
+{% highlight sh %}
+$ buildr [options] [tasks] [name=value]
+{% endhighlight %}
+
+There are several options you can use, for a full list of options type @buildr --help@:
+
+|_. Option                  |_. Usage |
+| @-f/--buildfile [file]@   | Specify the buildfile.                                  |
+| @-e/--environment [name]@ | Environment name (e.g. development, test, production).  |
+| @-h/--help@               | Display this help message.                              |
+| @-n/--nosearch@           | Do not search parent directories for the buildfile.     |
+| @-q/--quiet@              | Do not log messages to standard output.                 |
+| @-r/--require [file]@     | Require MODULE before executing buildfile.              |
+| @-t/--trace@              | Turn on invoke/execute tracing, enable full backtrace.  |
+| @-v/--version@            | Display the program version.                            |
+| @-P/--prereqs@            | Display tasks and dependencies, then exit.              |
+
+You can tell Buildr to run specific tasks and the order to run them.  For example:
+
+{% highlight sh %}
+# Clean and rebuild
+buildr clean build
+# Package and install
+buildr install
+{% endhighlight %}
+
+If you don't specify a task, Buildr will run the "@build@ task":building.html, compiling source code and running test cases.  Running a task may run other tasks as well, for example, running the @install@ task will also run @package@.
+
+There are several "environment variables":settings_profiles.html#env_vars that let you control how Buildr works, for example, to skip test cases during a build, or specify options for the JVM.  Depending on the variable, you may want to set it once in your environment, or set a different value each time you run Buildr.
+
+For example:
+
+{% highlight sh %}
+$ export JAVA_OPTS='-Xms1g -Xmx1g'
+$ buildr TEST=no
+{% endhighlight %}
+
+
+h2(#help). Help Tasks
+
+Buildr includes a number of informative tasks.  Currently that number stands at two, but we'll be adding more tasks in future releases.  These tasks report information from the Buildfile, so you need one to run them.  For more general help (version number, command line arguments, etc) use @buildr --help@.
+
+To start with, type:
+
+{% highlight sh %}
+$ buildr help
+{% endhighlight %}
+
+You can list the name and description of all your projects using the @help:projects@ task.  For example:
+
+{% highlight sh %}
+$ buildr help:projects
+killer-app                 # Code. Build. ??? Profit!
+killer-app:teh-api         # Abstract classes and interfaces
+killer-app:teh-impl        # All those implementation details
+killer-app:la-web          # What our users see
+{% endhighlight %}
+
+You are, of course, describing your projects for the sake of those who will maintain your code, right?  To describe a project, or a task, call the @desc@ method before the project or task definition.
+
+So next let's talk about "projects":projects.html.
+
+
+h2(#more). Learning More
+
+*Ruby*  It pays to pick up Ruby as a second (or first) programming language. It's fun, powerful and slightly addictive.  If you're interested in learning Ruby the language, a good place to start is "Programming Ruby: The Pragmatic Programmer's Guide":http://www.pragprog.com/titles/ruby/programming-ruby, fondly known as the _Pickaxe book_.
+
+For a quicker read (and much more humor), "Why’s (Poignant) Guide to Ruby":http://poignantguide.net/ruby/ is available online.  More resources are listed on the "ruby-lang web site":http://www.ruby-lang.org/en/documentation/.
+
+*Rake* Buildr is based on Rake, a Ruby build system that handles tasks and dependencies.  Check out the "Rake documentation":http://docs.rubyrake.org/ for more information.
+
+*AntWrap* Buildr uses AntWrap, for configuring and running Ant tasks.  You can learn more from the "Antwrap documentation":http://antwrap.rubyforge.org/.
+
+*YAML* Buildr uses YAML for its profiles.  You can "learn more about YAML here":http://www.yaml.org, and use this handy "YAML quick reference":http://www.yaml.org/refcard.html.

data/doc/languages.textile

@@ -0,0 +1,599 @@
+---
+layout: default
+title: Languages
+---
+
+
+h2(#java). Java
+
+
+h3. Compiling Java
+
+The Java compiler looks for source files in the project's @src/main/java@ directory, and defaults to compiling them into the @target/classes@ directory. It looks for test cases in the project's @src/test/java@ and defaults to compile them into the @target/test/classes@ directory.
+
+If you point the @compile@ task at any other source directory, it will use the Java compiler if any of these directories contains files with the extension @.java@.
+
+When using the Java compiler, if you don't specify the packaging type, it defaults to JAR.  If you don't specify the test framework, it defaults to JUnit.
+
+The Java compiler supports the following options:
+
+|_. Option        |_. Usage |
+| @:debug@        | Generates bytecode with debugging information.  You can also override this by setting the environment variable @debug@ to @off@. |
+| @:deprecation@  | If true, shows deprecation messages.  False by default. |
+| @:lint@         | Defaults to false.  Set this option to true to use all lint options, or specify a specific lint option (e.g. @:lint=>'cast'@). |
+| @:other@        | Array of options passed to the compiler (e.g. @:other=>'-implicit:none'@). |
+| @:source@       | Source code compatibility (e.g. '1.5'). |
+| @:target@       | Bytecode compatibility (e.g. '1.4'). |
+| @:warnings@     | Issue warnings when compiling.  True when running in verbose mode. |
+
+
+h3.  Testing with Java
+
+h4. JUnit
+
+The default test framework for Java projects is "JUnit 4":http://www.junit.org.
+
+When you use JUnit, the dependencies includes JUnit and "JMock":http://www.jmock.org, and Buildr picks up all test classes from the project by looking for classes that either subclass  @junit.framework.TestCase@, include methods annotated with @org.junit.Test@, or test suites annotated with @org.org.junit.runner.RunWith@.
+
+The JUnit test framework supports the following options:
+
+|_. Option        |_. Value |
+| @:fork@         | VM forking, defaults to true. |
+| @:clonevm@      | If true clone the VM each time it is forked. |
+| @:properties@   | Hash of system properties available to the test case. |
+| @:environment@  | Hash of environment variables available to the test case. |
+| @:java_args@    | Arguments passed as is to the JVM. |
+
+For example, to pass properties to the test case:
+
+{% highlight ruby %}
+test.using :properties=>{ :currency=>'USD' }
+{% endhighlight %}
+
+There are benefits to running test cases in separate VMs.  The default forking mode is @:once@, and you can change it by setting the @:fork@ option.
+
+|_. :fork=> |_. Behavior |
+| @:once@   | Create one VM to run all test classes in the project, separate VMs for each project. |
+| @:each@   | Create one VM for each test case class.  Slow but provides the best isolation between test classes. |
+| @false@   | Without forking, Buildr runs all test cases in a single VM.  This option runs fastest, but at the risk of running out of memory and causing test cases to interfere with each other. |
+
+You can see your tests running in the console, and if any tests fail, Buildr will show a list of the failed test classes.  In addition, JUnit produces text and XML report files in the project's @reports/junit@ directory.  You can use that to get around too-much-stuff-in-my-console, or when using an automated test system.
+
+In addition, you can get a consolidated XML or HTML report by running the @junit:report@ task.  For example:
+
+{% highlight sh %}
+$ buildr test junit:report test=all
+$ firefox report/junit/html/index.html
+{% endhighlight %}
+
+The @junit:report@ task generates a report from all tests run so far.  If you run tests in a couple of projects, it will generate a report only for these two projects.  The example above runs tests in all the projects before generating the reports.
+
+You can use the @build.yaml@ settings file to specify a particular version of JUnit or JMock.  For example, to force your build to use JUnit version 4.4 and JMock 2.0:
+
+{% highlight yaml %}
+junit: 4.4
+jmock: 2.0
+{% endhighlight %}
+
+
+h4. TestNG
+
+You can use "TestNG":http://testng.org instead of JUnit.  To select TestNG as the test framework, add this to your project:
+
+{% highlight ruby %}
+test.using :testng
+{% endhighlight %}
+
+Like all other options you can set with @test.using@, it affects the projects and all its sub-projects, so you only need to do this once at the top-most project to use TestNG throughout.  You can also mix TestNG and JUnit by setting different projects to use different frameworks, but you can't mix both frameworks in the same project.  (And yes, @test.using :junit@ will switch a project back to using JUnit)
+
+TestNG works much like JUnit, it gets included in the dependency list along with JMock, Buildr picks test classes that contain methods annotated with  @org.testng.annotations.Test@, and generates test reports in the @reports/testng@ directory.  At the moment we don't have consolidated HTML reports for TestNG.
+
+The TestNG test framework supports the following options:
+
+|_. Option        |_. Value |
+| @:properties@   | Hash of system properties available to the test case. |
+| @:java_args@    | Arguments passed as is to the JVM. |
+
+You can use the @build.yaml@ settings file to specify a particular version of TestNG, for example, to force your build to use TestNG 5.7:
+
+{% highlight yaml %}
+testng: 5.7
+{% endhighlight %}
+
+
+h4. JBehave
+
+"JBehave":http://jbehave.org/ is a pure Java BDD framework, stories and behaviour specifications are written in the Java language.
+
+To use JBehave in your project you can select it with @test.using :jbehave@.
+
+This framework will search for the following patterns under your project:
+
+{% highlight text %}
+src/spec/java/**/*Behaviour.java
+{% endhighlight %}
+
+Supports the following options:
+
+|_. Option        |_. Value |
+| @:properties@   | Hash of system properties available to the test case. |
+| @:java_args@    | Arguments passed as is to the JVM. |
+
+You can use the @build.yaml@ settings file to specify a particular version of JBehave, for example, to force your build to use JBehave 1.0.1:
+
+{% highlight yaml %}
+jbehave: 1.0.1
+{% endhighlight %}
+
+
+h3. Documentation
+
+Buildr offers support for using JavaDoc to generate documentation from any Java sources in a project.  This is done using the @doc@ task:
+
+{% highlight sh %}
+$ buildr doc
+{% endhighlight %}
+
+This will use the same @.java@ sources used by the @compile@ task to produce JavaDoc results in the @target/doc/@ directory.  By default, these sources are chosen only from the current project.  However, it is possible to override this and generate documentation from the sources in a sub-project (potentially more than one):
+
+{% highlight ruby %}
+define 'foo' do
+  # ...
+
+  doc.from projects('foo:bar', 'foo')
+
+  define 'bar' do
+    # ...
+  end
+end
+{% endhighlight %}
+
+With this configuration, the @doc@ task will use sources from both @foo:bar@ and
+@foo@.
+
+The @doc@ task supports any option that the @javadoc@ command does (e.g. @-windowtitle@).  To pass an option to the JavaDoc generator, simply specify it using the @doc@ method:
+
+{% highlight ruby %}
+define 'foo' do
+  # ...
+
+  doc :windowtitle => 'Abandon All Hope, Ye Who Enter Here', :private => true
+end
+{% endhighlight %}
+
+
+h2(#scala). Scala
+
+Before using Scala, you must first @require@ the Scala compiler:
+
+{% highlight ruby %}
+require 'buildr/scala'
+{% endhighlight %}
+
+By default, Buildr will attempt to use the latest stable release of Scala, which is currently Scala 2.8.0 as of July 2010.  Of course you can configure a specific version of Scala for your project by adding the following entry in @build.yaml@:
+
+{% highlight yaml %}
+scala.version: 2.8.0.Beta1  # Pick your version
+{% endhighlight %}
+
+Or, you can do the same programmatically:
+
+{% highlight yaml %}
+# Must be placed before require 'buildr/scala'
+Buildr.settings.build['scala.version'] = "2.8.0.Beta1"
+{% endhighlight %}
+
+You may also determine the version in use by querying the @Scala.version@ attribute:
+
+{% highlight ruby %}
+Scala.version       # => '2.8.0'
+{% endhighlight %}
+
+Regardless of how the Scala version is determined, if you have the same Scala version installed on your system and the SCALA_HOME environment variable points to it, then your local installation will be used.   Otherwise, Buildr will download it from the "Scala Tools repository":http://scala-tools.org/ which is automatically enlisted when you @require@ Scala.  The only drawback if you don't have a local installation is the FSC compiler won't be available.
+
+p(tip). For Mac users, if you have installed Scala via "MacPorts":http://www.macports.org/  Buildr will look in the
+@/opt/local/share/scala/@ directory if you have not set @SCALA_HOME@.
+
+
+h3. Compiling Scala
+
+The Scala compiler looks for source files in the project's @src/main/scala@  directory, and defaults to compiling them into the @target/classes@ directory.  It looks for test cases in the project's @src/test/scala@ and defaults to  compile them into the @target/test/classes@ directory.
+
+Any Java source files found in the @src/main/java@ directory will be compiled using the Scala/Java joint compiler into the @target/classes@ directory.  Both the Java and the Scala sources are compiled with an inclusive classpath, meaning that you may have a Java class which depends upon a Scala class which depends upon a Java class, all within the same project.  The Java sources will be compiled with the same dependencies as the Scala sources with the addition of the @scala-library.jar@ file as required for Scala interop.
+
+Note that you cannot use the Groovy *and* the Scala joint compilers in the same project.  If both are required, the Groovy joint compiler will take precedence.
++
+If you point the @compile@ task at any other source directory, it will use the  Scala compiler if any of these directories contains files with the extension @.scala@.  The joint compilation of Java sources may only be pointed at an alternative directory using the feature to redefine the @_(:src, :main, :java)@ path.
+
+When using the Scala compiler, if you don't specify the packaging type, it defaults to JAR.
+
+The Scala compiler supports the following options:
+
+|_. Option        |_. Usage |
+| @:debug@        | Generates bytecode with debugging information.  You can also override this by setting the environment variable @debug@ to @off@. |
+| @:deprecation@  | If true, shows deprecation messages.  False by default. |
+| @:optimise@     | Generates faster bytecode by applying optimisations to the program. |
+| @:other@        | Array of options passed to the compiler (e.g. @:other=>'-Xprint-types'@). |
+| @:make@         | Make strategy to be used by the compiler (e.g. @:make=>'transitive'@).  *Scala 2.8 only* |
+| @:target@       | Bytecode compatibility (e.g. '1.4'). |
+| @:warnings@     | Issue warnings when compiling.  True when running in verbose mode. |
+| @:javac@        | A hash of options passed to the @javac@ compiler verbatim. |
+
+h4. Fast Scala Compiler
+
+You may use @fsc@, the Fast Scala Compiler, which submits compilation jobs to a  compilation daemon, by setting the environment variable @USE_FSC@ to @yes@. Note that @fsc@ _may_ cache class libraries -- don't forget to run @fsc -reset@ if  you upgrade a library.
+
+h4. Rebuild detection
+
+The Scala 2.7 compiler task assumes that each @.scala@ source file generates a  corresponding @.class@ file under @target/classes@ (or @target/test/classses@  for tests). The source may generate more @.class@ files if it contains more than one class, object, trait or for anonymous functions and closures.
+
+For example, @src/main/scala/com/example/MyClass.scala@ should generate at least @target/classes/com/example/MyClass.class@. If that it not the case, Buildr will always recompile your sources because it will assume this is a new source file that has never been compiled before.
+
+Fortunately, Scala 2.8 provides a substantially better interface for implementing change detection.  Whenever you use Scala 2.8 (see below), Buildr will auto-detect the version and enable this feature dynamically.  After the @compile@ task runs, the relevant target directory will contain a @.scala-deps@ file, generated by the Scala compiler.  The manner in which this file is used can be configured using the @:make@ compiler option.  The following values are available:
+
+* @:all@ - Disables compiler-level change detection
+* @:changed@ - Only build changed files without considering file dependencies
+* @:immediate@ - *unknown*
+* @:transitive@ - Build changed files as well as their transitive file dependencies
+* @:transitivenocp@ - Build changed files as well as their transitive file dependencies (*default*)
+
+Please note that there are limits to compiler-level change detection.  Most notably, dependencies cannot be tracked across separate compilation targets.  This would cause problems in the case where an API has been changed in a main source file.  The test suite for the project will *not* be detected as requiring recompilation, potentially resulting in unexpected runtime exceptions.  When in doubt, run @clean@ to remove all dependency information.  In extreme cases, it is possible to completely disable compiler-level change detection by adding the following statement to your project definition:
+
+{% highlight ruby %}
+compile.using :make => :all
+{% endhighlight %}
+
+Effectively, this is telling the Scala compiler to ignore the information it has built up regarding source file dependencies.  When in this mode, only Buildr's change detection semantics remain in play (as described above).
+
+To avoid unusual behavior, compiler-level change detection is disabled whenever the joint Scala-Java compiler is used.  Thus, any @.java@ files in a project handled by the Scala compiler will cause the @:make@ option to be ignored and revert to the exclusive use of Buildr's change detection mechanism (as described above).
+
+h4. Scala 2.8
+
+As of version 1.4, Buildr has *non-default* support for Scala 2.8.  If your @SCALA_HOME@ environment variable is pointing to an installation of Scala 2.8, then Buildr will use that compiler and enable 2.8-specific features.
+
+As Scala 2.8 is currently pre-release, it is often desirable to maintain an installation of Scala 2.7 concurrently with Scala 2.8, defaulting to the former with the option to select the latter on a project-by-project basis.  This is most easily accomplished by setting @SCALA_HOME@ to point to the Scala 2.7 installation and @SCALA28_HOME@ to point to the Scala 2.8 installation.  With this configuration in place, Scala 2.8 can be selected for a specific project by dynamically reassigning @SCALA_HOME@ at the top of the buildfile (*before* @require 'buildr/scala'@):
+
+{% highlight ruby %}
+ENV['SCALA_HOME'] = ENV['SCALA28_HOME']
+
+require 'buildr/scala'
+...
+{% endhighlight %}
+
+h3. Testing with Scala
+
+Buildr supports two main Scala testing frameworks:   "ScalaTest":http://www.artima.com/scalatest and  "Specs":http://code.google.com/p/specs/.  "ScalaCheck":http://code.google.com/p/scalacheck/ is also supported within the confines of either of these two frameworks.  Thus, your Specs may use ScalaCheck properties, as may your ScalaTest suites.
+
+{% highlight ruby %}
+test.using(:scalatest)
+{% endhighlight %}
+
+h4. ScalaTest
+
+ScalaTest support is activated automatically when there are any @.scala@ source files contained in the @src/test/scala@ directory.  If you are not using this directory convention, you may force the test framework by using the @test.using :scalatest@ directive.
+
+Buildr automatically detects and runs tests that extend the @org.scalatest.Suite@ interface.
+
+A very simplistic test class might look like,
+
+{% highlight scala %}
+class MySuite extends org.scalatest.FunSuite {
+  test("addition") {
+    val sum = 1 + 1
+    assert(sum === 2)
+  }
+}
+{% endhighlight %}
+
+You can also pass properties to your tests by doing @test.using :properties => { 'name'=>'value' }@, and by overriding the @Suite.runTests@ method in a manner similar to:
+
+{% highlight scala %}
+import org.scalatest._
+
+class PropertyTestSuite extends FunSuite {
+  var properties = Map[String, Any]()
+
+  test("testProperty") {
+    assert(properties("name") === "value")
+  }
+
+  protected override def runTests(testName: Option[String],
+    reporter: Reporter, stopper: Stopper, includes: Set[String],
+    excludes: Set[String], properties: Map[String, Any])
+  {
+    this.properties = properties;
+    super.runTests(testName, reporter, stopper,
+                   includes, excludes, properties)
+  }
+}
+{% endhighlight %}
+
+h4. Specs
+
+Specs is automatically selected whenever there are @.scala@ source files under the @src/spec/scala@ directory.  It is also possible to force selection of the test framework by using the @test.using :specs@ directive.  This can sometimes be useful when Scala sources may be found in *both* @src/test/scala@ and @src/spec/scala@.  Normally in such cases, ScalaTest will have selection precedence, meaning that in case of a conflict between it and Specs, ScalaTest will be chosen.
+
+Any objects which extend the @org.specs.Specification@ superclass will be automatically detected and run.  Note that any *classes* which extend @Specification@ will also be invoked.  As such classes will not have a @main@ method, such an invocation will raise an error.
+
+A simple specification might look like this:
+
+{% highlight scala %}
+import org.specs._
+import org.specs.runner._
+
+object StringSpecs extends Specification {
+  "empty string" should {
+    "have a zero length" in {
+      "".length mustBe 0
+    }
+  }
+}
+{% endhighlight %}
+
+ScalaCheck is automatically added to the classpath when Specs is used.  However, JMock, Mockito, CGlib and similar are _not_.  This is to avoid downloading extraneous artifacts which are only used by a small percentage of specifications.  To use Specs with Mockito (or any other library) in a Buildr project, simply add the appropriate dependencies to @test.with@:
+
+{% highlight ruby %}
+MOCKITO = 'org.mockito:mockito-all:jar:1.7'
+CGLIB = 'cglib:cglib:jar:2.1_3'
+ASM = 'asm:asm:jar:1.5.3'
+OBJENESIS = 'org.objenesis:objenesis:jar:1.1'
+
+define 'killer-app' do
+  ...
+
+  test.with MOCKITO, CGLIB, ASM, OBJENESIS
+end
+{% endhighlight %}
+
+The dependencies for Specs's optional features are defined "here":http://code.google.com/p/specs/wiki/RunningSpecs#Dependencies.
+
+h4. ScalaCheck
+
+You may use ScalaCheck inside ScalaTest- and Specs-inherited classes.  Here is an example illustrating checks inside a ScalaTest suite,
+
+{% highlight scala %}
+import org.scalatest.prop.PropSuite
+import org.scalacheck.Arbitrary._
+import org.scalacheck.Prop._
+
+class MySuite extends PropSuite {
+
+  test("list concatenation") {
+    val x = List(1, 2, 3)
+    val y = List(4, 5, 6)
+    assert(x ::: y === List(1, 2, 3, 4, 5, 6))
+    check((a: List[Int], b: List[Int]) => a.size + b.size == (a ::: b).size)
+  }
+
+  test(
+    "list concatenation using a test method",
+    (a: List[Int], b: List[Int]) => a.size + b.size == (a ::: b).size
+  )
+}
+{% endhighlight %}
+
+
+h3. Documentation
+
+Buildr offers support for using ScalaDoc or VScalaDoc to generate documentation from any Scala sources in a project.  This is done using the @doc@ task:
+
+{% highlight sh %}
+$ buildr doc
+{% endhighlight %}
+
+This will use the same @.scala@ sources used by the @compile@ task to produce ScalaDoc results in the @target/doc/@ directory.  By default, these sources are chosen only from the current project.  However, it is possible to override this and generate documentation from the sources in a sub-project (potentially more than one):
+
+{% highlight ruby %}
+define 'foo' do
+  # ...
+
+  doc.from projects('foo:bar', 'foo')
+
+  define 'bar' do
+    # ...
+  end
+end
+{% endhighlight %}
+
+With this configuration, the @doc@ task will use sources from both @foo:bar@ and
+@foo@.
+
+The @doc@ task supports any option that the @scaladoc@ command does (e.g. @-windowtitle@).  To pass an option to the ScalaDoc (or VScalaDoc) generator, simply specify it using the @doc@ method:
+
+{% highlight ruby %}
+define 'foo' do
+  # ...
+
+  doc :windowtitle => 'Abandon All Hope, Ye Who Enter Here', :private => true
+end
+{% endhighlight %}
+
+By default, the @doc@ task will use the ScalaDoc generator on Scala projects.  To select the VScalaDoc generator, you must use the @doc.using@ invocation:
+
+{% highlight ruby %}
+define 'foo' do
+  doc.using :vscaladoc
+end
+{% endhighlight %}
+
+The @doc@ task is *not* joint-compilation aware.  Thus, it will only generate ScalaDoc for mixed-source projects, it will not attempt to generate both JavaDoc and ScalaDoc.
+
+
+h2(#groovy). Groovy
+
+h3. Compiling Groovy
+
+Before using the Groovy compiler, you must first require it on your buildfile:
+
+{% highlight ruby %}
+require 'buildr/java/groovyc'
+{% endhighlight %}
+
+Once loaded, the groovyc compiler will be automatically selected if any .groovy source files are found under @src/main/groovy@ directory, compiling them by default into the @target/classes@ directory.
+
+If the project has java sources in @src/main/java@ they will get compiled using the groovyc joint compiler.
+
+Sources found in @src/test/groovy@ are compiled into the @target/test/classes@.
+
+If you don't specify the packaging type, it defaults to JAR.
+
+The Groovy compiler supports the following options:
+
+|_. Option        |_. Usage |
+| @encoding@          | Encoding of source files. |
+| @verbose@           | Asks the compiler for verbose output, true when running in verbose mode. |
+| @fork@              | Whether to execute groovyc using a spawned instance of the JVM.  Defaults to no. |
+| @memoryInitialSize@ | The initial size of the memory for the underlying VM, if using fork mode, ignored otherwise.  Defaults to the standard VM memory setting. (Examples: @83886080@, @81920k@, or @80m@) |
+| @memoryMaximumSize@ | The maximum size of the memory for the underlying VM, if using fork mode, ignored otherwise.  Defaults to the standard VM memory setting. (Examples: @83886080@, @81920k@, or @80m@) |
+| @listfiles@         | Indicates whether the source files to be compiled will be listed.  Defaults to no. |
+| @stacktrace@        | If true each compile error message will contain a stacktrace. |
+| @warnings@          | Issue warnings when compiling.  True when running in verbose mode. |
+| @debug@             | Generates bytecode with debugging information.  Set from the debug environment variable/global option. |
+| @deprecation@       | If true, shows deprecation messages.  False by default. |
+| @optimise@          | Generates faster bytecode by applying optimisations to the program. |
+| @source@            | Source code compatibility. |
+| @target@            | Bytecode compatibility. |
+| @javac@             | Hash of options passed to the ant javac task. |
+
+
+h3. Testing with Groovy
+
+h4. EasyB
+
+"EasyB":http://www.easyb.org/ is a BDD framework using "Groovy":http://groovy.codehaus.org/.
+
+Specifications are written in the Groovy language, of course you get seamless Java integration as with all things groovy.
+
+To use this framework in your project you can select it with @test.using :easyb@.
+
+This framework will search for the following patterns under your project:
+
+{% highlight text %}
+src/spec/groovy/**/*Behavior.groovy
+src/spec/groovy/**/*Story.groovy
+{% endhighlight %}
+
+Supports the following options:
+
+|_. Option        |_. Value |
+| @:properties@   | Hash of system properties available to the test case. |
+| @:java_args@    | Arguments passed as is to the JVM. |
+| @:format@       | Report format, either @:txt@ or @:xml@ |
+
+
+h3. Documentation
+
+Buildr offers support for using GroovyDoc to generate documentation from any Groovy sources in a project.  This is done using the @doc@ task:
+
+{% highlight sh %}
+$ buildr doc
+{% endhighlight %}
+
+This will use the same @.groovy@ sources used by the @compile@ task to produce GroovyDoc results in the @target/doc/@ directory.  By default, these sources are chosen only from the current project.  However, it is possible to override this and generate documentation from the sources in a sub-project (potentially more than one):
+
+{% highlight ruby %}
+define 'foo' do
+  # ...
+
+  doc.from projects('foo:bar', 'foo')
+
+  define 'bar' do
+    # ...
+  end
+end
+{% endhighlight %}
+
+With this configuration, the @doc@ task will use sources from both @foo:bar@ and
+@foo@.
+
+The @doc@ task supports any option that the @groovydoc@ command does (e.g. @-windowtitle@).  To pass an option to the GroovyDoc generator, simply specify it using the @doc@ method:
+
+{% highlight ruby %}
+define 'foo' do
+  # ...
+
+  doc :windowtitle => 'Abandon All Hope, Ye Who Enter Here', :private => true
+end
+{% endhighlight %}
+
+The @doc@ task is *not* joint-compilation aware.  Thus, it will only generate GroovyDoc for mixed-source projects, it will not attempt to generate both JavaDoc and GroovyDoc.
+
+
+h2(#ruby).  Ruby
+
+h3.  Testing with Ruby
+
+Buildr provides integration with some ruby testing frameworks, allowing you to test your Java code with state of the art tools.
+
+Testing code is written in "Ruby":http://www.ruby-lang.org/en/ language, and is run by using "JRuby":http://jruby.codehaus.org/. That means you have access to all your Java classes and any Java or Ruby tool out there.
+
+Because of the use of JRuby, you will notice that running ruby tests is faster when running Buildr on JRuby, as in this case there's no need to run another JVM.
+
+p(tip). When not running on JRuby, Buildr will use the @JRUBY_HOME@ environment variable to find the JRuby installation directory.  If no @JRUBY_HOME@ is set or it points to an empty directory, Buildr will prompt you to either install JRuby manually or let it  extract it for you.
+
+You can use the @build.yaml@ settings file to specify a particular version of JRuby (defaults to @1.4.0@ as of Buildr 1.3.5).  For example:
+
+{% highlight yaml %}
+jruby: 1.3.1
+{% endhighlight %}
+
+h4.  RSpec
+
+"RSpec":http://rspec.info/ is the de-facto BDD framework for ruby. It's the framework used to test Buildr itself.
+
+To use this framework in your project you can select it with @test.using :rspec@.
+
+This framework will search for the following patterns under your project:
+
+{% highlight text %}
+src/spec/ruby/**/*_spec.rb
+{% endhighlight %}
+
+Supports the following options:
+
+|_. Option        |_. Value |
+| @:gems@         | Hash of gems needed before running the tests. Keys are gem names, values are the required gem version. An example use of this option would be to require the ci_reporter gem to generate xml reports |
+| @:requires@     | Array of ruby files to require before running the specs |
+| @:format@       | Array of valid RSpec @--format@ option values. Defaults to html report on the @reports@ directory and text progress |
+| @:output@       | File path to output dump. @false@ to supress output |
+| @:fork@         | Run the tests on a new java vm. (enabled unless running on JRuby) |
+| @:properties@   | Hash of system properties available to the test case. |
+| @:java_args@    | Arguments passed as is to the JVM. (only when fork is enabled) |
+
+h4.  JtestR
+
+"JtestR":http://jtestr.codehaus.org is a tool that makes it easier to test Java code with state of the art Ruby tools. Using JtestR you can describe your application behaviour using many testing frameworks at the same time.
+
+To use this framework in your project you can select it with @test.using :jtestr@.
+
+You can use the @build.yaml@ settings file to specify a particular version of JtestR (defaults to @0.3.1@).  For example:
+
+{% highlight yaml %}
+jtestr: 0.3.1
+{% endhighlight %}
+
+To customize TestNG/JUnit versions refer to their respective section.
+
+When selected, Buildr will configure JtestR to use your project/testing classpath and will search for the following test patterns for each framework supported by JtestR:
+
+|_. Framework                    |_. Patterns |
+| "RSpec":http://rspec.info      | Files in @src/spec/ruby@ ending with @*_spec.rb@ or @*_story.rb@ |
+| "TestUnit":http://ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html | Files in @src/spec/ruby@ ending with @*_test.rb@, @*Test.rb@ |
+| "Expectations":http://expectations.rubyforge.org/ | Files in @src/spec/ruby@ ending with @*_expect.rb@ |
+| "JUnit":http://www.junit.org   | Classes from @src/test/java@ that either subclass @junit.framework.TestCase@, include methods annotated with @org.junit.Test@, or test suites annotated with @org.org.junit.runner.RunWith@. |
+| "TestNG":http://testng.org     | Classes from @src/test/java@ annotated with  @org.testng.annotations.Test@ |
+
+If you create a @src/spec/ruby/jtestr_config.rb@ file, it will be loaded by JtestR, just after being configured by Buildr, this way you can configure as described on "JtestR guide":http://jtestr.codehaus.org/Configuration.
+
+p(tip). If you have a @jtestr_config.rb@ file, don't set @JtestR::result_handler@. Buildr uses its (@RSpecResultHandler@)  so that it can know which tests succeeded/failed, this handler is capable of using RSpec formatter classes, so that you can obtain an html report or use a custom rspec formatter with @JtestR@. See the @format@ option.
+
+Supports the following options:
+
+|_. Option        |_. Value |
+| @:config@       | The JtestR config file to be loaded after being configured by Buildr. Defaults to @src/spec/ruby/jtestr_config.rb@. |
+| @:gems@         | Hash of gems needed before running the tests. Keys are gem names, values are the required gem version. An example use of this option would be to require the ci_reporter gem to generate xml reports |
+| @:requires@     | Array of ruby files to require before running the specs |
+| @:format@       | Array of valid RSpec @--format@ option values. Defaults to html report on the @reports@ directory and text progress |
+| @:output@       | File path to output dump. @false@ to supress output |
+| @:fork@         | Run the tests on a new java vm. (enabled unless running on JRuby) |
+| @:properties@   | Hash of system properties available to the test case. (only when fork is enabled) |
+| @:java_args@    | Arguments passed as is to the JVM. (only when fork is enabled) |