You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@buildr.apache.org by do...@apache.org on 2013/10/06 09:17:12 UTC
svn commit: r1529576 [3/18] - in /buildr/site: ./ rdoc/ rdoc/Benchmark/
rdoc/Buildr/ rdoc/Buildr/ArchiveTask/ rdoc/Buildr/ArtifactNamespace/
rdoc/Buildr/Assets/ rdoc/Buildr/Checks/ rdoc/Buildr/Cobertura/
rdoc/Buildr/Cobertura/CoberturaExtension/ rdoc/B...
Modified: buildr/site/languages.html
URL: http://svn.apache.org/viewvc/buildr/site/languages.html?rev=1529576&r1=1529575&r2=1529576&view=diff
==============================================================================
--- buildr/site/languages.html (original)
+++ buildr/site/languages.html Sun Oct 6 07:17:05 2013
@@ -154,9 +154,7 @@
</table>
<p>For example, to pass properties to the test case:</p>
<div class="highlight"><pre><code class="ruby"><span class="nb">test</span><span class="o">.</span><span class="n">using</span> <span class="ss">:properties</span><span class="o">=></span><span class="p">{</span> <span class="ss">:currency</span><span class="o">=></span><span class="s1">'USD'</span> <span class="p">}</span>
-</code></pre>
-</div>
-<p>There are benefits to running test cases in separate VMs. The default forking mode is <code>:once</code>, and you can change it by setting the <code>:fork</code> option.</p>
+</code></pre></div><p>There are benefits to running test cases in separate VMs. The default forking mode is <code>:once</code>, and you can change it by setting the <code>:fork</code> option.</p>
<table>
<tr>
<th>:fork=> </th>
@@ -179,20 +177,14 @@
<p>In addition, you can get a consolidated <span class="caps">XML</span> or <span class="caps">HTML</span> report by running the <code>junit:report</code> task. For example:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr <span class="nb">test </span>junit:report <span class="nb">test</span><span class="o">=</span>all
<span class="nv">$ </span>firefox report/junit/html/index.html
-</code></pre>
-</div>
-<p>The <code>junit:report</code> 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.</p>
+</code></pre></div><p>The <code>junit:report</code> 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.</p>
<p>You can use the <code>build.yaml</code> 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:</p>
<div class="highlight"><pre><code class="yaml"><span class="l-Scalar-Plain">junit</span><span class="p-Indicator">:</span> <span class="l-Scalar-Plain">4.4</span>
<span class="l-Scalar-Plain">jmock</span><span class="p-Indicator">:</span> <span class="l-Scalar-Plain">2.0</span>
-</code></pre>
-</div>
-<h4>TestNG</h4>
+</code></pre></div><h4>TestNG</h4>
<p>You can use <a href="http://testng.org">TestNG</a> instead of JUnit. To select TestNG as the test framework, add this to your project:</p>
<div class="highlight"><pre><code class="ruby"><span class="nb">test</span><span class="o">.</span><span class="n">using</span> <span class="ss">:testng</span>
-</code></pre>
-</div>
-<p>Like all other options you can set with <code>test.using</code>, 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, <code>test.using :junit</code> will switch a project back to using JUnit)</p>
+</code></pre></div><p>Like all other options you can set with <code>test.using</code>, 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, <code>test.using :junit</code> will switch a project back to using JUnit)</p>
<p>TestNG works much like JUnit, it gets included in the dependency list along with JMock, Buildr picks test classes that contain methods annotated with <code>org.testng.annotations.Test</code>, and generates test reports in the <code>reports/testng</code> directory. At the moment we don’t have consolidated <span class="caps">HTML</span> reports for TestNG.</p>
<p>The TestNG test framework supports the following options:</p>
<table>
@@ -211,16 +203,12 @@
</table>
<p>You can use the <code>build.yaml</code> settings file to specify a particular version of TestNG, for example, to force your build to use TestNG 5.7:</p>
<div class="highlight"><pre><code class="yaml"><span class="l-Scalar-Plain">testng</span><span class="p-Indicator">:</span> <span class="l-Scalar-Plain">5.7</span>
-</code></pre>
-</div>
-<h4>JBehave</h4>
+</code></pre></div><h4>JBehave</h4>
<p><a href="http://jbehave.org/">JBehave</a> is a pure Java <span class="caps">BDD</span> framework, stories and behaviour specifications are written in the Java language.</p>
<p>To use JBehave in your project you can select it with <code>test.using :jbehave</code>.</p>
<p>This framework will search for the following patterns under your project:</p>
<div class="highlight"><pre><code class="text">src/spec/java/**/*Behaviour.java
-</code></pre>
-</div>
-<p>Supports the following options:</p>
+</code></pre></div><p>Supports the following options:</p>
<table>
<tr>
<th>Option </th>
@@ -237,14 +225,10 @@
</table>
<p>You can use the <code>build.yaml</code> settings file to specify a particular version of JBehave, for example, to force your build to use JBehave 1.0.1:</p>
<div class="highlight"><pre><code class="yaml"><span class="l-Scalar-Plain">jbehave</span><span class="p-Indicator">:</span> <span class="l-Scalar-Plain">1.0.1</span>
-</code></pre>
-</div>
-<h3>Documentation</h3>
+</code></pre></div><h3>Documentation</h3>
<p>Buildr offers support for using JavaDoc to generate documentation from any Java sources in a project. This is done using the <code>doc</code> task:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr doc
-</code></pre>
-</div>
-<p>This will use the same <code>.java</code> sources used by the <code>compile</code> task to produce JavaDoc results in the <code>target/doc/</code> 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):</p>
+</code></pre></div><p>This will use the same <code>.java</code> sources used by the <code>compile</code> task to produce JavaDoc results in the <code>target/doc/</code> 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):</p>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s1">'foo'</span> <span class="k">do</span>
<span class="c1"># ...</span>
@@ -254,9 +238,7 @@
<span class="c1"># ...</span>
<span class="k">end</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>With this configuration, the <code>doc</code> task will use sources from both <code>foo:bar</code> and<br />
+</code></pre></div><p>With this configuration, the <code>doc</code> task will use sources from both <code>foo:bar</code> and<br />
<code>foo</code>.</p>
<p>The <code>doc</code> task supports any option that the <code>javadoc</code> command does (e.g. <code>-windowtitle</code>). To pass an option to the JavaDoc generator, simply specify it using the <code>doc</code> method:</p>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s1">'foo'</span> <span class="k">do</span>
@@ -264,27 +246,17 @@
<span class="n">doc</span> <span class="ss">:windowtitle</span> <span class="o">=></span> <span class="s1">'Abandon All Hope, Ye Who Enter Here'</span><span class="p">,</span> <span class="ss">:private</span> <span class="o">=></span> <span class="kp">true</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<h2 id="scala">Scala</h2>
+</code></pre></div><h2 id="scala">Scala</h2>
<p>Before using Scala, you must first <code>require</code> the Scala compiler:</p>
<div class="highlight"><pre><code class="ruby"><span class="nb">require</span> <span class="s1">'buildr/scala'</span>
-</code></pre>
-</div>
-<p>By default, Buildr will attempt to use the latest stable release of Scala, which is currently Scala 2.9.0 as of May 2011. Of course you can configure a specific version of Scala for your project by adding the following entry in <code>build.yaml</code>:</p>
+</code></pre></div><p>By default, Buildr will attempt to use the latest stable release of Scala, which is currently Scala 2.9.0 as of May 2011. Of course you can configure a specific version of Scala for your project by adding the following entry in <code>build.yaml</code>:</p>
<div class="highlight"><pre><code class="yaml"><span class="l-Scalar-Plain">scala.version</span><span class="p-Indicator">:</span> <span class="l-Scalar-Plain">2.8.0.Beta1</span> <span class="c1"># Pick your version</span>
-</code></pre>
-</div>
-<p>Or, you can do the same programmatically:</p>
+</code></pre></div><p>Or, you can do the same programmatically:</p>
<div class="highlight"><pre><code class="yaml"><span class="c1"># Must be placed before require 'buildr/scala'</span>
<span class="l-Scalar-Plain">Buildr.settings.build['scala.version'] = "2.8.0.Beta1"</span>
-</code></pre>
-</div>
-<p>You may also determine the version in use by querying the <code>Scala.version</code> attribute:</p>
+</code></pre></div><p>You may also determine the version in use by querying the <code>Scala.version</code> attribute:</p>
<div class="highlight"><pre><code class="ruby"><span class="no">Scala</span><span class="o">.</span><span class="n">version</span> <span class="c1"># => '2.8.0'</span>
-</code></pre>
-</div>
-<p>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 <a href="http://oss.sonatype.org/content/repositories/releases">Sonatype repository</a> which is automatically enlisted when you <code>require</code> Scala. The only drawback if you don’t have a local installation is the <span class="caps">FSC</span> compiler won’t be available.</p>
+</code></pre></div><p>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 <a href="http://oss.sonatype.org/content/repositories/releases">Sonatype repository</a> which is automatically enlisted when you <code>require</code> Scala. The only drawback if you don’t have a local installation is the <span class="caps">FSC</span> compiler won’t be available.</p>
<p class="tip">For Mac users, if you have installed Scala via <a href="http://www.macports.org/">MacPorts</a> Buildr will look in the<br />
<code>/opt/local/share/scala/</code> directory if you have not set <code>SCALA_HOME</code>.</p>
<h3>Compiling Scala</h3>
@@ -354,9 +326,7 @@
</ul>
<p>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 <span class="caps">API</span> has been changed in a main source file. The test suite for the project will <strong>not</strong> be detected as requiring recompilation, potentially resulting in unexpected runtime exceptions. When in doubt, run <code>clean</code> 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:</p>
<div class="highlight"><pre><code class="ruby"><span class="n">compile</span><span class="o">.</span><span class="n">using</span> <span class="ss">:make</span> <span class="o">=></span> <span class="ss">:all</span>
-</code></pre>
-</div>
-<p>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).</p>
+</code></pre></div><p>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).</p>
<p>To avoid unusual behavior, compiler-level change detection is disabled whenever the joint Scala-Java compiler is used. Thus, any <code>.java</code> files in a project handled by the Scala compiler will cause the <code>:make</code> option to be ignored and revert to the exclusive use of Buildr’s change detection mechanism (as described above).</p>
<p><strong>Scala 2.9 and later</strong></p>
<p>Starting with Buildr 1.4.8, Buildr integrates with the <a href="https://github.com/typesafehub/zinc">Zinc</a> incremental compilation wrapper for <code>scalac</code>. Incremental compilation can be enabled 3 ways,</p>
@@ -364,23 +334,15 @@
<div class="highlight"><pre><code class="ruby"><span class="n">compile</span><span class="o">.</span><span class="n">using</span> <span class="ss">:incremental</span> <span class="o">=></span> <span class="kp">true</span>
<span class="n">compile</span><span class="o">.</span><span class="n">options</span><span class="o">.</span><span class="n">incremental</span> <span class="o">=</span> <span class="kp">true</span> <span class="c1"># same as above</span>
-</code></pre>
-</div>
-<p>Note that this won’t enable incremental compilation for both <code>compile</code> and <code>test.compile</code>, you would have to set options on both. For this reason, it’s recommended that you set the option on the project instead (see below).</p>
+</code></pre></div><p>Note that this won’t enable incremental compilation for both <code>compile</code> and <code>test.compile</code>, you would have to set options on both. For this reason, it’s recommended that you set the option on the project instead (see below).</p>
<p>2) By setting the project’s <code>scalac_options.incremental</code>,</p>
<div class="highlight"><pre><code class="ruby"><span class="n">project</span><span class="o">.</span><span class="n">scalac_options</span><span class="o">.</span><span class="n">incremental</span> <span class="o">=</span> <span class="kp">true</span>
-</code></pre>
-</div>
-<p>3) By setting the global <code>scalac.incremental</code> option,</p>
+</code></pre></div><p>3) By setting the global <code>scalac.incremental</code> option,</p>
<p>in your <code>buildfile</code>:</p>
<div class="highlight"><pre><code class="ruby"><span class="no">Buildr</span><span class="o">.</span><span class="n">settings</span><span class="o">.</span><span class="n">build</span><span class="o">[</span><span class="s1">'scalac.incremental'</span><span class="o">]</span> <span class="o">=</span> <span class="kp">true</span>
-</code></pre>
-</div>
-<p>or in your <code>build.yaml</code>:</p>
+</code></pre></div><p>or in your <code>build.yaml</code>:</p>
<div class="highlight"><pre><code class="yaml"><span class="l-Scalar-Plain">scalac.incremental</span><span class="p-Indicator">:</span> <span class="l-Scalar-Plain">true</span>
-</code></pre>
-</div>
-<h4>Support for different Scala versions</h4>
+</code></pre></div><h4>Support for different Scala versions</h4>
<p>Buildr defaults to the latest stable Scala version available at the time of the release if neither <code>SCALA_HOME</code> nor the <code>scala.version</code> build property are set.</p>
<p>If your <code>SCALA_HOME</code> environment variable points to an installation of Scala (2.7, 2.8, 2.9, …), then Buildr will use that compiler and enable version-specific features.</p>
<p>You may select the Scala version by dynamically in different ways,</p>
@@ -389,24 +351,16 @@
<span class="nb">require</span> <span class="s1">'buildr/scala'</span>
<span class="o">.</span><span class="n">.</span><span class="o">.</span>
-</code></pre>
-</div>
-<p>2) By setting the <code>scala.version</code> build property in your build.yaml file:</p>
+</code></pre></div><p>2) By setting the <code>scala.version</code> build property in your build.yaml file:</p>
<div class="highlight"><pre><code class="yaml"><span class="l-Scalar-Plain">scala.version</span><span class="p-Indicator">:</span> <span class="l-Scalar-Plain">2.9.1.RC1</span>
-</code></pre>
-</div>
-<p>3) By setting the <code>scala.version</code> build property in your buildfile:</p>
+</code></pre></div><p>3) By setting the <code>scala.version</code> build property in your buildfile:</p>
<div class="highlight"><pre><code class="ruby"><span class="nb">require</span> <span class="s1">'buildr/scala'</span>
<span class="o">.</span><span class="n">.</span><span class="o">.</span>
<span class="no">Buildr</span><span class="o">.</span><span class="n">settings</span><span class="o">.</span><span class="n">build</span><span class="o">[</span><span class="s1">'scala.version'</span><span class="o">]</span> <span class="o">=</span> <span class="s1">'2.10-M6'</span>
-</code></pre>
-</div>
-<h3>Testing with Scala</h3>
+</code></pre></div><h3>Testing with Scala</h3>
<p>Buildr supports two main Scala testing frameworks: <a href="http://www.artima.com/scalatest">ScalaTest</a> and <a href="http://code.google.com/p/specs/">Specs</a>. <a href="http://code.google.com/p/scalacheck/">ScalaCheck</a> is also supported within the confines of either of these two frameworks. Thus, your Specs may use ScalaCheck properties, as may your ScalaTest suites.</p>
<div class="highlight"><pre><code class="ruby"><span class="nb">test</span><span class="o">.</span><span class="n">using</span><span class="p">(</span><span class="ss">:scalatest</span><span class="p">)</span>
-</code></pre>
-</div>
-<h4>ScalaTest</h4>
+</code></pre></div><h4>ScalaTest</h4>
<p>ScalaTest support is activated automatically when there are any <code>.scala</code> source files contained in the <code>src/test/scala</code> directory. If you are not using this directory convention, you may force the test framework by using the <code>test.using :scalatest</code> directive.</p>
<p>Buildr automatically detects and runs tests that extend the <code>org.scalatest.Suite</code> interface.</p>
<p>A very simplistic test class might look like,</p>
@@ -416,9 +370,7 @@
<span class="n">assert</span><span class="o">(</span><span class="n">sum</span> <span class="o">===</span> <span class="mi">2</span><span class="o">)</span>
<span class="o">}</span>
<span class="o">}</span>
-</code></pre>
-</div>
-<p>You can also pass properties to your tests by doing <code>test.using :properties => { 'name'=>'value' }</code>, and by overriding the <code>Suite.runTests</code> method in a manner similar to:</p>
+</code></pre></div><p>You can also pass properties to your tests by doing <code>test.using :properties => { 'name'=>'value' }</code>, and by overriding the <code>Suite.runTests</code> method in a manner similar to:</p>
<div class="highlight"><pre><code class="scala"><span class="k">import</span> <span class="nn">org.scalatest._</span>
<span class="k">class</span> <span class="nc">PropertyTestSuite</span> <span class="k">extends</span> <span class="nc">FunSuite</span> <span class="o">{</span>
@@ -437,9 +389,7 @@
<span class="n">includes</span><span class="o">,</span> <span class="n">excludes</span><span class="o">,</span> <span class="n">properties</span><span class="o">)</span>
<span class="o">}</span>
<span class="o">}</span>
-</code></pre>
-</div>
-<h4>Specs</h4>
+</code></pre></div><h4>Specs</h4>
<p>Specs is automatically selected whenever there are <code>.scala</code> source files under the <code>src/spec/scala</code> directory. It is also possible to force selection of the test framework by using the <code>test.using :specs</code> directive. This can sometimes be useful when Scala sources may be found in <strong>both</strong> <code>src/test/scala</code> and <code>src/spec/scala</code>. Normally in such cases, ScalaTest will have selection precedence, meaning that in case of a conflict between it and Specs, ScalaTest will be chosen.</p>
<p>Any objects which extend the <code>org.specs.Specification</code> superclass will be automatically detected and run. Note that any <strong>classes</strong> which extend <code>Specification</code> will also be invoked. As such classes will not have a <code>main</code> method, such an invocation will raise an error.</p>
<p>A simple specification might look like this:</p>
@@ -453,9 +403,7 @@
<span class="o">}</span>
<span class="o">}</span>
<span class="o">}</span>
-</code></pre>
-</div>
-<p>ScalaCheck is automatically added to the classpath when Specs is used. However, JMock, Mockito, CGlib and similar are <em>not</em>. 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 <code>test.with</code>:</p>
+</code></pre></div><p>ScalaCheck is automatically added to the classpath when Specs is used. However, JMock, Mockito, CGlib and similar are <em>not</em>. 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 <code>test.with</code>:</p>
<div class="highlight"><pre><code class="ruby"><span class="no">MOCKITO</span> <span class="o">=</span> <span class="s1">'org.mockito:mockito-all:jar:1.7'</span>
<span class="no">CGLIB</span> <span class="o">=</span> <span class="s1">'cglib:cglib:jar:2.1_3'</span>
<span class="no">ASM</span> <span class="o">=</span> <span class="s1">'asm:asm:jar:1.5.3'</span>
@@ -466,9 +414,7 @@
<span class="nb">test</span><span class="o">.</span><span class="n">with</span> <span class="no">MOCKITO</span><span class="p">,</span> <span class="no">CGLIB</span><span class="p">,</span> <span class="no">ASM</span><span class="p">,</span> <span class="no">OBJENESIS</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>The dependencies for Specs’s optional features are defined <a href="http://code.google.com/p/specs/wiki/RunningSpecs#Dependencies">here</a>.</p>
+</code></pre></div><p>The dependencies for Specs’s optional features are defined <a href="http://code.google.com/p/specs/wiki/RunningSpecs#Dependencies">here</a>.</p>
<h4>ScalaCheck</h4>
<p>You may use ScalaCheck inside ScalaTest- and Specs-inherited classes. Here is an example illustrating checks inside a ScalaTest suite,</p>
<div class="highlight"><pre><code class="scala"><span class="k">import</span> <span class="nn">org.scalatest.prop.PropSuite</span>
@@ -489,14 +435,10 @@
<span class="o">(</span><span class="n">a</span><span class="k">:</span> <span class="kt">List</span><span class="o">[</span><span class="kt">Int</span><span class="o">],</span> <span class="n">b</span><span class="k">:</span> <span class="kt">List</span><span class="o">[</span><span class="kt">Int</span><span class="o">])</span> <span class="k">=></span> <span class="n">a</span><span class="o">.</span><span class="n">size</span> <span class="o">+</span> <span class="n">b</span><span class="o">.</span><span class="n">size</span> <span class="o">==</span> <span class="o">(</span><span class="n">a</span> <span class="o">:::</span> <span class="n">b</span><span class="o">).</span><span class="n">size</span>
<span class="o">)</span>
<span class="o">}</span>
-</code></pre>
-</div>
-<h3>Documentation</h3>
+</code></pre></div><h3>Documentation</h3>
<p>Buildr offers support for using ScalaDoc or VScalaDoc to generate documentation from any Scala sources in a project. This is done using the <code>doc</code> task:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr doc
-</code></pre>
-</div>
-<p>This will use the same <code>.scala</code> sources used by the <code>compile</code> task to produce ScalaDoc results in the <code>target/doc/</code> 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):</p>
+</code></pre></div><p>This will use the same <code>.scala</code> sources used by the <code>compile</code> task to produce ScalaDoc results in the <code>target/doc/</code> 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):</p>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s1">'foo'</span> <span class="k">do</span>
<span class="c1"># ...</span>
@@ -506,9 +448,7 @@
<span class="c1"># ...</span>
<span class="k">end</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>With this configuration, the <code>doc</code> task will use sources from both <code>foo:bar</code> and<br />
+</code></pre></div><p>With this configuration, the <code>doc</code> task will use sources from both <code>foo:bar</code> and<br />
<code>foo</code>.</p>
<p>The <code>doc</code> task supports any option that the <code>scaladoc</code> command does (e.g. <code>-windowtitle</code>). To pass an option to the ScalaDoc (or VScalaDoc) generator, simply specify it using the <code>doc</code> method:</p>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s1">'foo'</span> <span class="k">do</span>
@@ -516,22 +456,16 @@
<span class="n">doc</span> <span class="ss">:windowtitle</span> <span class="o">=></span> <span class="s1">'Abandon All Hope, Ye Who Enter Here'</span><span class="p">,</span> <span class="ss">:private</span> <span class="o">=></span> <span class="kp">true</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>By default, the <code>doc</code> task will use the ScalaDoc generator on Scala projects. To select the VScalaDoc generator, you must use the <code>doc.using</code> invocation:</p>
+</code></pre></div><p>By default, the <code>doc</code> task will use the ScalaDoc generator on Scala projects. To select the VScalaDoc generator, you must use the <code>doc.using</code> invocation:</p>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s1">'foo'</span> <span class="k">do</span>
<span class="n">doc</span><span class="o">.</span><span class="n">using</span> <span class="ss">:vscaladoc</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>The <code>doc</code> task is <strong>not</strong> joint-compilation aware. Thus, it will only generate ScalaDoc for mixed-source projects, it will not attempt to generate both JavaDoc and ScalaDoc.</p>
+</code></pre></div><p>The <code>doc</code> task is <strong>not</strong> joint-compilation aware. Thus, it will only generate ScalaDoc for mixed-source projects, it will not attempt to generate both JavaDoc and ScalaDoc.</p>
<h2 id="groovy">Groovy</h2>
<h3>Compiling Groovy</h3>
<p>Before using the Groovy compiler, you must first require it on your buildfile:</p>
<div class="highlight"><pre><code class="ruby"><span class="nb">require</span> <span class="s1">'buildr/java/groovyc'</span>
-</code></pre>
-</div>
-<p>Once loaded, the groovyc compiler will be automatically selected if any .groovy source files are found under <code>src/main/groovy</code> directory, compiling them by default into the <code>target/classes</code> directory.</p>
+</code></pre></div><p>Once loaded, the groovyc compiler will be automatically selected if any .groovy source files are found under <code>src/main/groovy</code> directory, compiling them by default into the <code>target/classes</code> directory.</p>
<p>If the project has java sources in <code>src/main/java</code> they will get compiled using the groovyc joint compiler.</p>
<p>Sources found in <code>src/test/groovy</code> are compiled into the <code>target/test/classes</code>.</p>
<p>If you don’t specify the packaging type, it defaults to <span class="caps">JAR</span>.</p>
@@ -606,9 +540,7 @@
<p>This framework will search for the following patterns under your project:</p>
<div class="highlight"><pre><code class="text">src/spec/groovy/**/*Behavior.groovy
src/spec/groovy/**/*Story.groovy
-</code></pre>
-</div>
-<p>Supports the following options:</p>
+</code></pre></div><p>Supports the following options:</p>
<table>
<tr>
<th>Option </th>
@@ -630,9 +562,7 @@ src/spec/groovy/**/*Story.groovy
<h3>Documentation</h3>
<p>Buildr offers support for using GroovyDoc to generate documentation from any Groovy sources in a project. This is done using the <code>doc</code> task:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr doc
-</code></pre>
-</div>
-<p>This will use the same <code>.groovy</code> sources used by the <code>compile</code> task to produce GroovyDoc results in the <code>target/doc/</code> 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):</p>
+</code></pre></div><p>This will use the same <code>.groovy</code> sources used by the <code>compile</code> task to produce GroovyDoc results in the <code>target/doc/</code> 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):</p>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s1">'foo'</span> <span class="k">do</span>
<span class="c1"># ...</span>
@@ -642,9 +572,7 @@ src/spec/groovy/**/*Story.groovy
<span class="c1"># ...</span>
<span class="k">end</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>With this configuration, the <code>doc</code> task will use sources from both <code>foo:bar</code> and<br />
+</code></pre></div><p>With this configuration, the <code>doc</code> task will use sources from both <code>foo:bar</code> and<br />
<code>foo</code>.</p>
<p>The <code>doc</code> task supports any option that the <code>groovydoc</code> command does (e.g. <code>-windowtitle</code>). To pass an option to the GroovyDoc generator, simply specify it using the <code>doc</code> method:</p>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s1">'foo'</span> <span class="k">do</span>
@@ -652,9 +580,7 @@ src/spec/groovy/**/*Story.groovy
<span class="n">doc</span> <span class="ss">:windowtitle</span> <span class="o">=></span> <span class="s1">'Abandon All Hope, Ye Who Enter Here'</span><span class="p">,</span> <span class="ss">:private</span> <span class="o">=></span> <span class="kp">true</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>The <code>doc</code> task is <strong>not</strong> joint-compilation aware. Thus, it will only generate GroovyDoc for mixed-source projects, it will not attempt to generate both JavaDoc and GroovyDoc.</p>
+</code></pre></div><p>The <code>doc</code> task is <strong>not</strong> joint-compilation aware. Thus, it will only generate GroovyDoc for mixed-source projects, it will not attempt to generate both JavaDoc and GroovyDoc.</p>
<h2 id="ruby">Ruby</h2>
<h3>Testing with Ruby</h3>
<p>Buildr provides integration with some ruby testing frameworks, allowing you to test your Java code with state of the art tools.</p>
@@ -663,16 +589,12 @@ src/spec/groovy/**/*Story.groovy
<p class="tip">When not running on JRuby, Buildr will use the <code>JRUBY_HOME</code> environment variable to find the JRuby installation directory. If no <code>JRUBY_HOME</code> 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.</p>
<p>You can use the <code>build.yaml</code> settings file to specify a particular version of JRuby (defaults to <code>1.4.0</code> as of Buildr 1.3.5). For example:</p>
<div class="highlight"><pre><code class="yaml"><span class="l-Scalar-Plain">jruby</span><span class="p-Indicator">:</span> <span class="l-Scalar-Plain">1.3.1</span>
-</code></pre>
-</div>
-<h4>RSpec</h4>
+</code></pre></div><h4>RSpec</h4>
<p><a href="http://rspec.info/">RSpec</a> is the de-facto <span class="caps">BDD</span> framework for ruby. It’s the framework used to test Buildr itself.</p>
<p>To use this framework in your project you can select it with <code>test.using :rspec</code>.</p>
<p>This framework will search for the following patterns under your project:</p>
<div class="highlight"><pre><code class="text">src/spec/ruby/**/*_spec.rb
-</code></pre>
-</div>
-<p>Supports the following options:</p>
+</code></pre></div><p>Supports the following options:</p>
<table>
<tr>
<th>Option </th>