Added: dev/buildr/1.5.0/site/releasing.html
==============================================================================
--- dev/buildr/1.5.0/site/releasing.html (added)
+++ dev/buildr/1.5.0/site/releasing.html Sat Sep 17 06:23:20 2016
@@ -0,0 +1,158 @@
+<html>
+  <head>
+    <meta content='text/html;charset=UTF-8' http-equiv='Content-Type'>
+    <title>buildr &mdash; Releasing</title>
+    <style type='text/css'>
+      @import 'css/default.css';
+      @import 'css/syntax.css';
+    </style>
+    <style media='print' type='text/css'>
+      @import 'css/print.css';
+    </style>
+    <meta content='Official Buildr documentation from the people in the know' 
name='subject'>
+    <link href='images/favicon.png' rel='shortcut icon'>
+  </head>
+  <body>
+    <div id='wrap'>
+      <div id='header'>
+        <a href='http://buildr.apache.org/' title="Build like you code"><img 
alt='buildr' src='images/buildr.png'></a>
+        <div class='tagline'>Build like you code</div>
+      </div>
+      <div id='pages'>
+        <ol class='toc'>
+          <li>Start Here
+            <ol class="toc">
+              <li><a href='index.html'>Welcome</a></li>
+              <li><a href='quick_start.html'>Quick Start</a></li>
+              <li><a href='installing.html'>Installing & Running</a></li>
+              <li><a 
href='http://cwiki.apache.org/confluence/display/BUILDR/Index'>Community 
Wiki</a></li>
+            </ol>
+          </li>
+          <li>Using Buildr
+            <ol class="toc">
+              <li><a href='buildr.pdf'>This Guide (PDF)</a></li>
+              <li><a href='projects.html'>Projects</a></li>
+              <li><a href='building.html'>Building</a></li>
+              <li><a href='artifacts.html'>Artifacts</a></li>
+              <li><a href='packaging.html'>Packaging</a></li>
+              <li><a href='testing.html'>Testing</a></li>
+              <li><a href='releasing.html'>Releasing</a></li>
+              <li><a href='settings_profiles.html'>Settings/Profiles</a></li>
+              <li><a href='languages.html'>Languages</a></li>
+              <li><a href='more_stuff.html'>More Stuff</a></li>
+              <li><a href='extending.html'>Extending Buildr</a></li>
+              <li><a 
href='http://cwiki.apache.org/confluence/display/BUILDR/Buildr+HowTos'>How-Tos</a></li>
+            </ol>
+          </li>
+          <li>Reference
+            <ol class="toc">
+              <li><a href='rdoc/Buildr.html'>API</a></li>
+              <li><a href='http://docs.rubyrake.org'>Rake</a></li>
+              <li><a href='https://rubygems.org/gems/Antwrap'>Antwrap</a></li>
+              <li><a 
href='http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions'>Troubleshooting</a></li>
+            </ol>
+          </li>
+          <li>Get Involved
+            <ol class="toc">
+              <li><a href='download.html'>Download</a></li>
+              <li><a href='mailing_lists.html'>Mailing Lists</a></li>
+              <li><a href='http://www.twitter.com/buildr'>Twitter</a></li>
+              <li><a 
href='http://issues.apache.org/jira/browse/Buildr'>Issues/Bugs</a></li>
+              <li><a href='https://builds.apache.org/view/A-F/view/Buildr'>CI 
Jobs</a></li>
+              <li><a href='contributing.html'>Contributing</a></li>
+            </ol>
+          </li>
+          <li>
+            <form action='http://www.google.com/' 
onsubmit="document.getElementById('gQuery').value += ' site:buildr.apache.org'">
+              <input name='q' size='20' type='text' id='gQuery'>
+              <input name='sa' type='submit' value='Search'>
+              <img alt='Google Custom Search' 
src='http://www.google.com/coop/images/google_custom_search_smnar.gif'>
+            </form>
+          </li>
+        </ol>
+      </div>
+      <div id='content'>
+        <h1 id='releasing'>Releasing</h1>
+        <ol class="toc"><li><a href="#default">What does a release 
do?</a></li><li><a href="#custom_version">How to specify my own version number 
scheme?</a></li><li><a href="#custom_tag_and_msg">How to specify my own tag 
name and commit message?</a></li></ol>
+        <p>Now that we built and tested our awesome software, let&#8217;s tell 
the world and release it.</p>
+<p>Each buildfile can specify the current version with a constant named 
<code>VERSION_NUMBER</code>  or <code>THIS_VERSION</code>.</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="no">THIS_VERSION</span> <span class="o">=</span> 
<span class="s2">&quot;1.0.0-SNAPSHOT&quot;</span>
+
+<span class="n">define</span> <span class="s1">&#39;killer-app&#39;</span> 
<span class="k">do</span>
+
+  <span class="n">project</span><span class="o">.</span><span 
class="n">version</span> <span class="o">=</span> <span 
class="no">THIS_VERSION</span>
+
+  <span class="c1"># ...</span>
+<span class="k">end</span></code></pre></figure><h2 id="default">What does a 
release do?</h2>
+<p>The default behavior of the <code>Release</code> task is the following:</p>
+<ol>
+       <li>Check that the version to be released and the next version are 
different</li>
+       <li>Check that the project is being tracked by Git or Subversion</li>
+       <li>Package, test and deploy the artifacts using 
<code>THIS_VERSION</code> value minus the <code>-SNAPSHOT</code> suffix (if 
any)</li>
+       <li>Tag the repository with the released version number</li>
+       <li>Update the value of <code>THIS_VERSION</code> in the buildfile with 
the next version number</li>
+</ol>
+<p>Buildr will increment the last digit of the 3-digit versioni number if 
<code>THIS_VERSION</code> ends with <code>-SNAPSHOT</code>.<br />
+So, at the end of a release, the buildfile now looks like this:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="no">THIS_VERSION</span> <span class="o">=</span> 
<span class="s2">&quot;1.0.1-SNAPSHOT&quot;</span>
+
+<span class="n">define</span> <span class="s1">&#39;killer-app&#39;</span> 
<span class="k">do</span>
+
+  <span class="n">project</span><span class="o">.</span><span 
class="n">version</span> <span class="o">=</span> <span 
class="no">THIS_VERSION</span>
+
+  <span class="c1"># ...</span>
+<span class="k">end</span></code></pre></figure><p>And the Git repository now 
contains two new commits and a new tag.</p>
+<figure class="highlight"><pre><code class="language-sh" 
data-lang="sh">~/w/killer-app<span class="o">[</span>master<span 
class="o">]</span><span class="nv">$git</span> ol -4
+c1af3d5  <span class="o">(</span>HEAD, origin/master, master<span 
class="o">)</span> Changed version number to 1.0.1-SNAPSHOT
+dd35015  <span class="o">(</span>tag: 1.0.0<span class="o">)</span> Changed 
version number to 1.0.0
+76c96e7  Last fix before the release</code></pre></figure><h2 
id="custom_version">How to specify my own version number scheme?</h2>
+<p>If <code>THIS_VERSION</code> does not contain <code>-SNAPSHOT</code>, 
Buildr delegates the resolution of the next version number to the user which 
has 2 differents ways to express her wishes: <code>Release.next_version</code> 
or the environment variable <code>NEXT_VERSION</code>.</p>
+<h3 id="next_version_proc">Using Release.next_version</h3>
+<p>The <code>Release</code> class can receive the next version of the 
buildfile. This could be a string or a proc that would receive the current 
version and return the next version.</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="no">THIS_VERSION</span> <span class="o">=</span> 
<span class="s2">&quot;1.0.0-SNAPSHOT&quot;</span>
+
+<span class="c1"># a string</span>
+<span class="no">Release</span><span class="o">.</span><span 
class="n">next_version</span> <span class="o">=</span> <span 
class="s2">&quot;2.0.0-SNAPSHOT&quot;</span>
+
+<span class="c1"># or a proc - equivalent result</span>
+<span class="no">Release</span><span class="o">.</span><span 
class="n">next_version</span> <span class="o">=</span> <span 
class="nb">lambda</span> <span class="k">do</span> <span 
class="o">|</span><span class="n">this_version</span><span class="o">|</span> 
<span class="c1"># 2.0.0-SNAPSHOT</span>
+    <span class="n">new_version</span> <span class="o">=</span> <span 
class="no">THIS_VERSION</span><span class="o">.</span><span 
class="n">split</span> <span class="sr">/\./</span>
+    <span class="n">new_version</span><span class="o">[</span><span 
class="mi">0</span><span class="o">]</span> <span class="o">=</span> <span 
class="n">new_version</span><span class="o">[</span><span 
class="mi">0</span><span class="o">].</span><span class="n">to_i</span> <span 
class="o">+</span> <span class="mi">1</span>
+    <span class="n">new_version</span><span class="o">[</span><span 
class="mi">1</span><span class="o">]</span> <span class="o">=</span> <span 
class="mi">0</span>
+    <span class="n">new_version</span><span class="o">[</span><span 
class="mi">2</span><span class="o">]</span> <span class="o">=</span> <span 
class="s1">&#39;0-SNAPSHOT&#39;</span>
+    <span class="n">new_version</span><span class="o">.</span><span 
class="n">join</span> <span class="s1">&#39;.&#39;</span>
+<span class="k">end</span>
+
+<span class="n">define</span> <span class="s1">&#39;killer-app&#39;</span> 
<span class="k">do</span>
+
+  <span class="n">project</span><span class="o">.</span><span 
class="n">version</span> <span class="o">=</span> <span 
class="no">THIS_VERSION</span>
+
+  <span class="c1"># ...</span>
+<span class="k">end</span></code></pre></figure><h3 
id="next_version_envvar">Using the environment variable NEXT_VERSION</h3>
+<p>If the environment variable <code>NEXT_VERSION</code> is set, Buildr will 
use this value to update <code>THIS_VERSION</code> at the end of the 
release.</p>
+<p>For conveniency, this variable is case insensitive.</p>
+<p>So, all 3 following commands will run a release with a custom new 
version:</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span>buildr release <span class="nv">next_version</span><span 
class="o">=</span><span class="s2">&quot;1.0.0-rc1&quot;</span>
+<span class="nv">$ </span>env <span class="nv">next_version</span><span 
class="o">=</span><span class="s2">&quot;1.0.0-rc1&quot;</span> buildr release
+<span class="nv">$ </span>env <span class="nv">NEXT_VERSION</span><span 
class="o">=</span><span class="s2">&quot;1.0.0-rc1&quot;</span> buildr 
release</code></pre></figure><p>Those commands will generate the Buildfile 
below:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="no">THIS_VERSION</span> <span class="o">=</span> 
<span class="s2">&quot;1.0.0-rc1&quot;</span>
+
+<span class="n">define</span> <span class="s1">&#39;killer-app&#39;</span> 
<span class="k">do</span>
+
+  <span class="n">project</span><span class="o">.</span><span 
class="n">version</span> <span class="o">=</span> <span 
class="no">THIS_VERSION</span>
+
+  <span class="c1"># ...</span>
+<span class="k">end</span></code></pre></figure><p>The environment variable 
<code>NEXT_VERSION</code> has precedence over Release.next_version.</p>
+<h3 id="alternate_version_file">Using an alternate version file</h3>
+<p>To avoid dealing with conflicts over the Buildfile, you can store the 
version inside version.rb next to it.</p>
+<p>version.rb:<br />
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="no">THIS_VERSION</span> <span class="o">=</span> 
<span class="s2">&quot;1.0.0-rc1&quot;</span></code></pre></figure></p>
+<p>Your Buildfile should import version.rb like so:<br />
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="nb">require</span> <span 
class="no">File</span><span class="o">.</span><span class="n">join</span><span 
class="p">(</span><span class="no">File</span><span class="o">.</span><span 
class="n">dirname</span><span class="p">(</span><span 
class="bp">__FILE__</span><span class="p">),</span> <span 
class="s1">&#39;version.rb&#39;</span><span 
class="p">)</span></code></pre></figure></p>
+<h2 id="custom_tag_and_msg">How to specify my own tag name and commit 
message?</h2>
+<p>As explained earlier, Buildr will create two new commits and a new tag in 
the version control system. Similarly to <code>Release.next_version</code>, the 
commit message and the tag name can be customized with 
<code>Release.message</code> and <code>Release.tag_name</code>. Both could be 
strings or procs that would receive the released version 
<code>THIS_VERSION</code> without <code>-SNAPSHOT</code>.</p>
+      </div>
+      <div id='footer'>Copyright &copy; 2007-2016 The Apache Software 
Foundation</div>
+    </div>
+  </body>
+</html>

Added: dev/buildr/1.5.0/site/scripts/install-jruby.sh
==============================================================================
--- dev/buildr/1.5.0/site/scripts/install-jruby.sh (added)
+++ dev/buildr/1.5.0/site/scripts/install-jruby.sh Sat Sep 17 06:23:20 2016
@@ -0,0 +1,44 @@
+#!/bin/sh
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements.  See the NOTICE file distributed with this
+# work for additional information regarding copyright ownership.  The ASF
+# licenses this file to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#    http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  See the
+# License for the specific language governing permissions and limitations under
+# the License.
+if [ -z `which jruby` ] ; then
+  version=1.6.2
+  target=/opt/jruby
+  echo "Installing JRuby ${version} in ${target}"
+  sudo mkdir -p $(dirname ${target})
+  wget 
http://jruby.org.s3.amazonaws.com/downloads/${version}/jruby-bin-${version}.tar.gz
+  tar -xz < jruby-bin-${version}.tar.gz
+  sudo mv jruby-${version} ${target}
+  rm jruby-bin-${version}.tar.gz
+  export PATH=$PATH:${target}
+  if [ -e ~/.bash_profile ] ; then
+    echo "export PATH=${target}/bin:\$PATH" >> ~/.bash_profile
+  elif [ -e ~/.profile ] ; then
+    echo "export PATH=${target}/bin:\$PATH" >> ~/.profile
+  else
+    echo "You need to add ${target}/bin to the PATH"
+  fi
+fi
+
+if [ `which buildr` ] ; then
+  echo "Updating to the latest version of Buildr"
+  sudo jruby -S gem update buildr
+else
+  echo "Installing the latest version of Buildr"
+  sudo jruby -S gem install buildr
+fi
+echo
+
+jruby -S buildr --version

Propchange: dev/buildr/1.5.0/site/scripts/install-jruby.sh
------------------------------------------------------------------------------
    svn:executable = *

Added: dev/buildr/1.5.0/site/scripts/install-linux.sh
==============================================================================
--- dev/buildr/1.5.0/site/scripts/install-linux.sh (added)
+++ dev/buildr/1.5.0/site/scripts/install-linux.sh Sat Sep 17 06:23:20 2016
@@ -0,0 +1,73 @@
+#!/bin/sh
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements.  See the NOTICE file distributed with this
+# work for additional information regarding copyright ownership.  The ASF
+# licenses this file to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#    http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  See the
+# License for the specific language governing permissions and limitations under
+# the License.
+if [ -z `which ruby` ] ; then
+  echo "You do not have Ruby 1.8.6 ..."
+  # yum comes first since some people have apt-get installed in addition to 
yum.
+  # urpmi is added in case of mandriva : apt-get or yum are working for 
mandriva too
+  if [ `which yum` ] ; then
+    echo "Installing Ruby using yum"
+    sudo yum install ruby rubygems ruby-devel gcc
+  elif [ `which apt-get` ] ; then
+    echo "Installing Ruby using apt-get"
+    # ruby package does not contain RDoc, IRB, etc; ruby-full is a 
meta-package.
+    # build-essentials not installed by default in Ubuntu, required for C 
extensions.
+    sudo apt-get install ruby-full ruby1.8-dev libopenssl-ruby build-essential
+    # RubyGems broken on Ubuntu, installing directly from source.
+    echo "Installing RubyGems from RubyForge"
+    wget http://production.cf.rubygems.org/rubygems/rubygems-1.3.7.tgz
+    tar xzf rubygems-1.3.7.tgz
+    cd rubygems-1.3.7
+    sudo ruby setup.rb
+    cd ..
+    rm -rf rubygems-1.3.7
+    # ruby is same as ruby1.8, we need gem that is same as gem1.8
+    sudo ln -s /usr/bin/gem1.8 /usr/bin/gem
+  elif [ `which urpmi` ] ; then
+    echo "Installing Ruby using urpmi"
+    sudo urpmi ruby rubygems ruby-devel gcc
+    if [ $? -ne 0 ] ; then
+      echo "URPMI install error"
+      exit 1
+    fi
+  else
+    echo "Can only install Ruby 1.8.6 using apt-get, yum or urpmi, and can't 
find any of them"
+    exit 1
+  fi
+  echo
+fi
+
+if [ -z $JAVA_HOME ] ; then
+  echo "Please set JAVA_HOME before proceeding"
+  exit 1
+fi
+
+if [ $(gem --version) \< '1.3.7' ] ; then
+  echo "Upgrading to latest version of RubyGems"
+  sudo gem update --system
+  sudo update_rubygems
+  echo
+fi
+
+if [ `which buildr` ] ; then
+  echo "Updating to the latest version of Buildr"
+  sudo env JAVA_HOME=$JAVA_HOME gem update buildr
+else
+  echo "Installing the latest version of Buildr"
+  sudo env JAVA_HOME=$JAVA_HOME gem install buildr
+fi
+echo
+
+buildr --version

Propchange: dev/buildr/1.5.0/site/scripts/install-linux.sh
------------------------------------------------------------------------------
    svn:executable = *

Added: dev/buildr/1.5.0/site/scripts/install-osx.sh
==============================================================================
--- dev/buildr/1.5.0/site/scripts/install-osx.sh (added)
+++ dev/buildr/1.5.0/site/scripts/install-osx.sh Sat Sep 17 06:23:20 2016
@@ -0,0 +1,52 @@
+#!/bin/sh
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements.  See the NOTICE file distributed with this
+# work for additional information regarding copyright ownership.  The ASF
+# licenses this file to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#    http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  See the
+# License for the specific language governing permissions and limitations under
+# the License.
+version=$(ruby --version)
+if [ ${version:5:5} \< '1.8.6' ] ; then
+  echo "You do not have Ruby 1.8.6 or later, attempting to install a newer 
version."
+  if [ `which port` ] ; then
+    echo "Installing Ruby using MacPorts"
+    sudo port install ruby rb-rubygems
+  elif [ `which fink` ] ; then
+    echo "Installing Ruby using Fink"
+    sudo fink install ruby ruby18-dev rubygems-rb18
+  else
+    echo "Can only upgrade to Ruby 1.8.6 using either MacPorts or Fink, and 
can't find either one"
+    exit 1
+  fi
+  echo
+fi
+
+if [ -z $JAVA_HOME ] ; then
+  echo "Setting JAVA_HOME"
+  export JAVA_HOME=/Library/Java/Home
+fi
+
+if [ $(gem --version) \< '1.3.1' ] ; then
+  echo "Upgrading to latest version of RubyGems"
+  sudo gem update --system
+  echo
+fi
+
+if [ `which buildr` ] ; then
+  echo "Updating to the latest version of Buildr"
+  sudo env JAVA_HOME=$JAVA_HOME gem update buildr
+else
+  echo "Installing the latest version of Buildr"
+  sudo env JAVA_HOME=$JAVA_HOME gem install buildr
+fi
+echo
+
+buildr --version

Propchange: dev/buildr/1.5.0/site/scripts/install-osx.sh
------------------------------------------------------------------------------
    svn:executable = *

Added: dev/buildr/1.5.0/site/settings_profiles.html
==============================================================================
--- dev/buildr/1.5.0/site/settings_profiles.html (added)
+++ dev/buildr/1.5.0/site/settings_profiles.html Sat Sep 17 06:23:20 2016
@@ -0,0 +1,303 @@
+<html>
+  <head>
+    <meta content='text/html;charset=UTF-8' http-equiv='Content-Type'>
+    <title>buildr &mdash; Settings/Profiles</title>
+    <style type='text/css'>
+      @import 'css/default.css';
+      @import 'css/syntax.css';
+    </style>
+    <style media='print' type='text/css'>
+      @import 'css/print.css';
+    </style>
+    <meta content='Official Buildr documentation from the people in the know' 
name='subject'>
+    <link href='images/favicon.png' rel='shortcut icon'>
+  </head>
+  <body>
+    <div id='wrap'>
+      <div id='header'>
+        <a href='http://buildr.apache.org/' title="Build like you code"><img 
alt='buildr' src='images/buildr.png'></a>
+        <div class='tagline'>Build like you code</div>
+      </div>
+      <div id='pages'>
+        <ol class='toc'>
+          <li>Start Here
+            <ol class="toc">
+              <li><a href='index.html'>Welcome</a></li>
+              <li><a href='quick_start.html'>Quick Start</a></li>
+              <li><a href='installing.html'>Installing & Running</a></li>
+              <li><a 
href='http://cwiki.apache.org/confluence/display/BUILDR/Index'>Community 
Wiki</a></li>
+            </ol>
+          </li>
+          <li>Using Buildr
+            <ol class="toc">
+              <li><a href='buildr.pdf'>This Guide (PDF)</a></li>
+              <li><a href='projects.html'>Projects</a></li>
+              <li><a href='building.html'>Building</a></li>
+              <li><a href='artifacts.html'>Artifacts</a></li>
+              <li><a href='packaging.html'>Packaging</a></li>
+              <li><a href='testing.html'>Testing</a></li>
+              <li><a href='releasing.html'>Releasing</a></li>
+              <li><a href='settings_profiles.html'>Settings/Profiles</a></li>
+              <li><a href='languages.html'>Languages</a></li>
+              <li><a href='more_stuff.html'>More Stuff</a></li>
+              <li><a href='extending.html'>Extending Buildr</a></li>
+              <li><a 
href='http://cwiki.apache.org/confluence/display/BUILDR/Buildr+HowTos'>How-Tos</a></li>
+            </ol>
+          </li>
+          <li>Reference
+            <ol class="toc">
+              <li><a href='rdoc/Buildr.html'>API</a></li>
+              <li><a href='http://docs.rubyrake.org'>Rake</a></li>
+              <li><a href='https://rubygems.org/gems/Antwrap'>Antwrap</a></li>
+              <li><a 
href='http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions'>Troubleshooting</a></li>
+            </ol>
+          </li>
+          <li>Get Involved
+            <ol class="toc">
+              <li><a href='download.html'>Download</a></li>
+              <li><a href='mailing_lists.html'>Mailing Lists</a></li>
+              <li><a href='http://www.twitter.com/buildr'>Twitter</a></li>
+              <li><a 
href='http://issues.apache.org/jira/browse/Buildr'>Issues/Bugs</a></li>
+              <li><a href='https://builds.apache.org/view/A-F/view/Buildr'>CI 
Jobs</a></li>
+              <li><a href='contributing.html'>Contributing</a></li>
+            </ol>
+          </li>
+          <li>
+            <form action='http://www.google.com/' 
onsubmit="document.getElementById('gQuery').value += ' site:buildr.apache.org'">
+              <input name='q' size='20' type='text' id='gQuery'>
+              <input name='sa' type='submit' value='Search'>
+              <img alt='Google Custom Search' 
src='http://www.google.com/coop/images/google_custom_search_smnar.gif'>
+            </form>
+          </li>
+        </ol>
+      </div>
+      <div id='content'>
+        <h1 id='settings/profiles'>Settings/Profiles</h1>
+        <ol class="toc"><li><a href="#env_vars">Environment 
Variables</a></li><li><a href="#personal">Personal Settings</a></li><li><a 
href="#build">Build Settings</a></li><li><a href="#variable">Non constant 
settings</a></li><li><a href="#environments">Environments</a></li><li><a 
href="#profiles">Profiles</a></li></ol>
+        <h2 id="env_vars">Environment Variables</h2>
+<p>Buildr uses several environment variables that help you control how it 
works. Some environment variables you will only set once or change 
infrequently.  You can set these in your profile, OS settings or any tool you 
use to launch Buildr (e.g. continuous integration).</p>
+<p>For example:</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span><span class="nb">export </span><span 
class="nv">HTTP_PROXY</span><span 
class="o">=</span>http://myproxy:8080</code></pre></figure><p>There are other 
environment variables you will want to set when running Buildr, for example, to 
do a full build without running the tests:</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span>buildr <span class="nb">test</span><span 
class="o">=</span>no</code></pre></figure><p>For convenience, the environment 
variables <code>TEST</code> and <code>DEBUG</code> are case insensitive, you 
can use either <code>test=no</code> or <code>TEST=no</code>. Any other 
environment variable names are case sensitive.</p>
+<p>You can also set environment variables from within your Buildfile.  For 
example, if you discover that building your project requires gobs of <span 
class="caps">JVM</span> heap space, and you want all other team members to run 
with the same settings:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="c1"># This project builds a lot of code.</span>
+<span class="no">ENV</span><span class="o">[</span><span 
class="s1">&#39;JAVA_OPTS&#39;</span><span class="o">]</span> <span 
class="o">||=</span> <span class="s1">&#39;-Xms1g 
-Xmx1g&#39;</span></code></pre></figure><p>Make sure to set any environment 
variables at the very top of the Buildfile, above any Ruby statement (even 
<code>require</code>).</p>
+<p class="tip">Using <code>||=</code> sets the environment variable, if not 
already set, so it&#8217;s still possible for other developers to override this 
environment variable without modifying the Buildfile.</p>
+<p>Buildr supports the following environment variables:</p>
+<table>
+       <tr>
+               <th>Variable    </th>
+               <th>Description </th>
+       </tr>
+       <tr>
+               <td> <code>BUILDR_ENV</code>  </td>
+               <td> Environment name (development, production, test, etc). 
Another way to set this is using the <code>-e</code> command line option. </td>
+       </tr>
+       <tr>
+               <td> <code>DEBUG</code>       </td>
+               <td> Set to <code>no/off</code> if you want Buildr to compile 
without debugging information (default when running the <code>release</code> 
task, see <a href="building.html#compiling">Compiling</a>). </td>
+       </tr>
+       <tr>
+               <td> <code>HOME</code>        </td>
+               <td> Your home directory. </td>
+       </tr>
+       <tr>
+               <td> <code>HTTP_PROXY</code>  </td>
+               <td> <span class="caps">URL</span> for <span 
class="caps">HTTP</span> proxy server (see <a 
href="artifacts.html#repositories">Specifying Repositories</a>). </td>
+       </tr>
+       <tr>
+               <td> <code>HTTPS_PROXY</code> </td>
+               <td> <span class="caps">URL</span> for <span 
class="caps">HTTPS</span> proxy server (see <a 
href="artifacts.html#repositories">Specifying Repositories</a>). </td>
+       </tr>
+       <tr>
+               <td> <code>IGNORE_BUILDFILE</code> </td>
+               <td> Set to &#8220;true&#8221; or &#8220;yes&#8221; to ignore 
changes in Buildfile or its dependencies when running tests. </td>
+       </tr>
+       <tr>
+               <td> <code>JAVA_HOME</code>   </td>
+               <td> Points to your <span class="caps">JDK</span>, required 
when using Java and Ant. </td>
+       </tr>
+       <tr>
+               <td> <code>JAVA_OPTS</code>   </td>
+               <td> Command line options to pass to the <span 
class="caps">JDK</span> (e.g. <code>'-Xms1g'</code>). </td>
+       </tr>
+       <tr>
+               <td> <code>M2_REPO</code>     </td>
+               <td> Location of the Maven2 local repository.  Defaults to the 
<code>.m2</code> directory in your home directory (<code>ENV['HOME']</code>). 
</td>
+       </tr>
+       <tr>
+               <td> <code>NO_PROXY</code>    </td>
+               <td> Comma separated list of hosts and domain that should not 
be proxied (see <a href="artifacts.html#repositories">Specifying 
Repositories</a>).  </td>
+       </tr>
+       <tr>
+               <td> <code>TEST</code>        </td>
+               <td> Set to <code>no/off</code> to tell Buildr to skip tests, 
or <code>all</code> to tell Buildr to run all tests and ignore failures (see <a 
href="testing.html#running">Running Tests</a>). </td>
+       </tr>
+       <tr>
+               <td> <code>USER</code>        </td>
+               <td> Tasks that need your user name, for example to log to 
remote servers, will use this environment variable. </td>
+       </tr>
+</table>
+<p class="note">Buildr does not check any of the arguments in 
<code>JAVA_OPTS</code>.  A common mistake is to pass an option like 
<code>mx512mb</code>, where it should be <code>Xmx512mb</code>. Make sure to 
double check <code>JAVA_OPTS</code>.</p>
+<p>Some extensions may use additional environment variables, and of course, 
you can always add your own.  This example uses two environment variables for 
specifying the username and password:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="n">repositories</span><span 
class="o">.</span><span class="n">release_to</span><span 
class="o">[</span><span class="ss">:username</span><span class="o">]</span> 
<span class="o">=</span> <span class="no">ENV</span><span 
class="o">[</span><span class="s1">&#39;USERNAME&#39;</span><span 
class="o">]</span>
+<span class="n">repositories</span><span class="o">.</span><span 
class="n">release_to</span><span class="o">[</span><span 
class="ss">:password</span><span class="o">]</span> <span class="o">=</span> 
<span class="no">ENV</span><span class="o">[</span><span 
class="s1">&#39;PASSWORD&#39;</span><span 
class="o">]</span></code></pre></figure><p>The same works for the 
<code>repositories.snapshot_to</code> hash.</p>
+<h2 id="personal">Personal Settings</h2>
+<p>Some things clearly do not belong in the Buildfile.  For example, the 
username and password you use to upload releases.  If you&#8217;re working in a 
team or on an open source project, you&#8217;d want to keep these in a separate 
place.</p>
+<p>You may want to use personal settings for picking up a different location 
for the local repository, or use a different set of preferred remote 
repositories, and so forth.</p>
+<p>The prefered way to store personal settings is to create a 
<code>.buildr/settings.yaml</code> file under your home directory. Settings 
stored there will be applied the same across all builds.</p>
+<p>Here&#8217;s an example <code>settings.yaml</code>:</p>
+<figure class="highlight"><pre><code class="language-yaml" 
data-lang="yaml"><span class="c1"># The repositories hash is read automatically 
by buildr.</span>
+<span class="l-Scalar-Plain">repositories</span><span 
class="p-Indicator">:</span>
+
+  <span class="c1"># customize user local maven2 repository location</span>
+  <span class="l-Scalar-Plain">local</span><span class="p-Indicator">:</span> 
<span class="l-Scalar-Plain">some/path/to/my_repo</span>
+
+  <span class="c1"># prefer the local or nearest mirrors</span>
+  <span class="l-Scalar-Plain">remote</span><span class="p-Indicator">:</span>
+   <span class="p-Indicator">-</span> <span 
class="l-Scalar-Plain">https://intra.net/maven2</span>
+   <span class="p-Indicator">-</span> <span 
class="l-Scalar-Plain">http://example.com</span>
+   
+  <span class="c1"># specify the corporate mirror</span>
+  <span class="l-Scalar-Plain">mirrors</span><span class="p-Indicator">:</span>
+   <span class="p-Indicator">-</span> <span 
class="l-Scalar-Plain">http://www.corporateserver001.com/repo</span>
+
+  <span class="l-Scalar-Plain">release_to</span><span 
class="p-Indicator">:</span>
+    <span class="l-Scalar-Plain">url</span><span class="p-Indicator">:</span> 
<span class="l-Scalar-Plain">http://intra.net/maven2</span>
+    <span class="l-Scalar-Plain">username</span><span 
class="p-Indicator">:</span> <span class="l-Scalar-Plain">john</span>
+    <span class="l-Scalar-Plain">password</span><span 
class="p-Indicator">:</span> <span class="l-Scalar-Plain">secret</span>
+
+<span class="c1"># You can place settings of your own, and reference 
them</span>
+<span class="c1"># on buildfiles.</span>
+<span class="l-Scalar-Plain">im</span><span class="p-Indicator">:</span>
+  <span class="l-Scalar-Plain">server</span><span class="p-Indicator">:</span> 
<span class="l-Scalar-Plain">jabber.company.com</span>
+  <span class="l-Scalar-Plain">usr</span><span class="p-Indicator">:</span> 
<span class="l-Scalar-Plain">notif...@company-jabber.com</span>
+  <span class="l-Scalar-Plain">pwd</span><span class="p-Indicator">:</span> 
<span class="l-Scalar-Plain">secret</span></code></pre></figure><p>Later your 
buildfile or addons can reference user preferences using the  hash returned by 
the <code>Buildr.settings.user</code> accessor.</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="n">task</span> <span 
class="s1">&#39;release-notification&#39;</span> <span class="k">do</span>
+ <span class="n">usr</span><span class="p">,</span> <span 
class="n">pwd</span><span class="p">,</span> <span class="n">server</span> 
<span class="o">=</span> <span class="n">settings</span><span 
class="o">.</span><span class="n">user</span><span class="o">[</span><span 
class="s1">&#39;im&#39;</span><span class="o">].</span><span 
class="n">values_at</span><span class="p">(</span><span 
class="s1">&#39;usr&#39;</span><span class="p">,</span> <span 
class="s1">&#39;pwd&#39;</span><span class="p">,</span> <span 
class="s1">&#39;server&#39;</span><span class="p">)</span>
+ <span class="n">jabber</span> <span class="o">=</span> <span 
class="no">JabberAPI</span><span class="o">.</span><span 
class="n">new</span><span class="p">(</span><span class="n">server</span><span 
class="p">,</span> <span class="n">usr</span><span class="p">,</span> <span 
class="n">pwd</span><span class="p">)</span>
+ <span class="n">jabber</span><span class="o">.</span><span 
class="n">msg</span><span class="p">(</span><span class="s2">&quot;We are 
pleased to announce the last stable version </span><span 
class="si">#{</span><span class="no">VERSION</span><span 
class="si">}</span><span class="s2">&quot;</span><span class="p">)</span>
+<span class="k">end</span></code></pre></figure><h2 id="build">Build 
Settings</h2>
+<p>Build settings are local to the project being built, and are placed in the 
<code>build.yaml</code> file located in the same directory that the 
<code>buildfile</code>. Normally this file would be managed by the project 
revision control system, so settings here are shared between developers.</p>
+<p>They help keep the buildfile and build.yaml file simple and readable, 
working to the advantages of each one.  Example for build settings are gems, 
repositories and artifacts used by that build.</p>
+<figure class="highlight"><pre><code class="language-yaml" 
data-lang="yaml"><span class="c1"># This project requires the following ruby 
gems, buildr addons</span>
+<span class="l-Scalar-Plain">gems</span><span class="p-Indicator">:</span>
+  <span class="c1"># Suppose we want to notify developers when testcases 
fail.</span>
+  <span class="p-Indicator">-</span> <span 
class="l-Scalar-Plain">buildr-twitter-notifier-addon &gt;=1</span>
+  <span class="c1"># we test with ruby mock objects</span>
+  <span class="p-Indicator">-</span> <span class="l-Scalar-Plain">mocha</span>
+  <span class="p-Indicator">-</span> <span 
class="l-Scalar-Plain">ci_reporter</span>
+
+<span class="c1"># The artifact declarations will be automatically loaded by 
buildr, so that</span>
+<span class="c1"># you can reference artifacts by name (a ruby-symbol) on your 
buildfile.</span>
+<span class="l-Scalar-Plain">artifacts</span><span class="p-Indicator">:</span>
+  <span class="l-Scalar-Plain">spring</span><span class="p-Indicator">:</span> 
<span class="l-Scalar-Plain">org.springframework:spring:jar:2.0</span>
+  <span class="l-Scalar-Plain">log4j</span><span class="p-Indicator">:</span> 
<span class="l-Scalar-Plain">log4j:log4j:jar:1.0</span>
+  <span class="l-Scalar-Plain">j2ee</span><span class="p-Indicator">:</span> 
<span class="l-Scalar-Plain">geronimo-spec:geronimo-spec-j2ee:jar:1.4-rc4</span>
+
+<span class="c1"># Of course project settings can be defined here</span>
+<span class="l-Scalar-Plain">twitter</span><span class="p-Indicator">:</span>
+  <span class="l-Scalar-Plain">notify</span><span class="p-Indicator">:</span>
+    <span class="l-Scalar-Plain">test_failure</span><span 
class="p-Indicator">:</span> <span class="l-Scalar-Plain">unless-modified</span>
+    <span class="l-Scalar-Plain">compile_failure</span><span 
class="p-Indicator">:</span> <span class="l-Scalar-Plain">never</span>
+  <span class="l-Scalar-Plain">developers</span><span 
class="p-Indicator">:</span>
+    <span class="p-Indicator">-</span> <span class="l-Scalar-Plain">joe</span>
+    <span class="p-Indicator">-</span> <span class="l-Scalar-Plain">jane</span>
+
+<span class="l-Scalar-Plain">jira</span><span class="p-Indicator">:</span>
+  <span class="l-Scalar-Plain">uri</span><span class="p-Indicator">:</span> 
<span 
class="l-Scalar-Plain">https://jira.corp.org</span></code></pre></figure><p>When
 buildr is loaded, required ruby gems will be installed if needed, thus adding 
features like the imaginary twitter notifier addon.</p>
+<p>Artifacts defined on <code>build.yaml</code> can be referenced on your 
buildfile by supplying the ruby symbol to the <code>Buildr.artifact</code> and 
<code>Buildr.artifacts</code> methods.  The <code>compile.with</code>, 
<code>test.with</code> methods can also be given these names.</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="n">define</span> <span 
class="s1">&#39;my_project&#39;</span> <span class="k">do</span>
+  <span class="n">compile</span><span class="o">.</span><span 
class="n">with</span> <span class="n">artifacts</span><span 
class="p">(</span><span class="ss">:log4j</span><span class="p">,</span> <span 
class="ss">:j2ee</span><span class="p">)</span>
+  <span class="nb">test</span><span class="o">.</span><span 
class="n">with</span> <span class="ss">:spring</span><span class="p">,</span> 
<span class="ss">:j2ee</span>
+<span class="k">end</span></code></pre></figure><p>Build settings can be 
retreived using the <code>Buildr.settings.build</code> accessor.</p>
+<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"> 
<span class="n">task</span> <span class="s1">&#39;create_patch&#39;</span> 
<span class="k">do</span>
+   <span class="n">patch</span> <span class="o">=</span> <span 
class="no">Git</span><span class="o">.</span><span 
class="n">create_patch</span> <span class="ss">:interactive</span> <span 
class="o">=&gt;</span> <span class="kp">true</span>
+   <span class="k">if</span> <span class="n">patch</span> <span 
class="o">&amp;&amp;</span> <span class="n">agree</span><span 
class="p">(</span><span class="s2">&quot;Would you like to request inclusion of 
</span><span class="si">#{</span><span class="n">patch</span><span 
class="si">}</span><span class="s2">&quot;</span><span class="p">)</span>
+     <span class="n">jira</span> <span class="o">=</span> <span 
class="no">Jira</span><span class="o">.</span><span class="n">new</span><span 
class="p">(</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">&#39;jira&#39;</span><span class="o">][</span><span 
class="s1">&#39;uri&#39;</span><span class="o">]</span> <span 
class="p">)</span>  <span class="c1"># submit a patch</span>
+     <span class="n">jira</span><span class="o">.</span><span 
class="n">create</span><span class="p">(</span><span 
class="ss">:improvement</span><span class="p">,</span> <span 
class="n">patch</span><span class="o">.</span><span 
class="n">summary</span><span class="p">,</span> <span 
class="ss">:attachment</span> <span class="o">=&gt;</span> <span 
class="n">patch</span><span class="o">.</span><span class="n">blob</span><span 
class="p">)</span>
+   <span class="k">end</span>
+ <span class="k">end</span></code></pre></figure><h2 id="variable">Non 
constant settings</h2>
+<p>Before loading the Buildfile, Buildr will attempt to load two other files: 
the <code>buildr.rb</code> file in the <code>.buildr</code> directory under 
your home directory, followed by the <code>_buildr.rb</code> (or 
<code>.buildr.rb</code>) file it finds in the build directory.</p>
+<p>The loading order allows you to place global settings that affect all your 
builds in your <code>buildr.rb</code>, but also over-ride those with settings 
for a given project.</p>
+<p>Here&#8217;s an example <code>buildr.rb</code>:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="c1"># Only I should know that</span>
+<span class="n">repositories</span><span class="o">.</span><span 
class="n">release_to</span><span class="o">[</span><span 
class="ss">:username</span><span class="o">]</span> <span class="o">=</span> 
<span class="s1">&#39;assaf&#39;</span>
+<span class="n">repositories</span><span class="o">.</span><span 
class="n">release_to</span><span class="o">[</span><span 
class="ss">:password</span><span class="o">]</span> <span class="o">=</span> 
<span class="s1">&#39;supersecret&#39;</span>
+<span class="c1"># Search here first, it&#39;s faster</span>
+<span class="n">repositories</span><span class="o">.</span><span 
class="n">remote</span> <span class="o">&lt;&lt;</span> <span 
class="s1">&#39;http://inside-the-firewall&#39;</span></code></pre></figure><p 
class="note">Buildr 1.3 and earlier used the file <code>buildr.rb</code> 
directly in your home directory.  Starting with version 1.4, Buildr loads 
<code>buildr.rb</code> from the <code>.buildr</code> directory under your home 
directory in preference.  If you use Buildr 1.3 and earlier and don&#8217;t 
want to duplicate your settings, you can move you existing 
<code>buildr.rb</code> under the <code>.buildr</code> directory and create a 
new <code>buildr.rb</code> in your home directory containing:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="c1"># Backward compatibility:  Buildr 1.4+ uses 
$HOME/.buildr/buildr.rb</span>
+<span class="nb">load</span> <span class="no">File</span><span 
class="o">.</span><span class="n">expand_path</span><span 
class="p">(</span><span class="s1">&#39;buildr.rb&#39;</span><span 
class="p">,</span> <span class="no">Buildr</span><span class="o">.</span><span 
class="n">application</span><span class="o">.</span><span 
class="n">home_dir</span><span class="p">)</span></code></pre></figure><h2 
id="environments">Environments</h2>
+<p>One common use case is adapting the build to different environments.  For 
example, to compile code with debugging information during development and 
testing, but strip it for production.  Another example is using different 
databases for development, testing and production, or running services at 
different URLs.</p>
+<p>So let&#8217;s start by talking about the build environment.  Buildr has a 
global attributes that indicates which environment it&#8217;s running in, 
accessible from the <code>environment</code> method.  You can set the current 
build environment in one of two ways.  Using the <code>-e/--environment</code> 
command line option:</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span>buildr -e <span class="nb">test</span>
+<span class="o">(</span>in /home/john/project, <span 
class="nb">test</span><span class="o">)</span></code></pre></figure><p>Or by 
setting the environment variable <code>BUILDR_ENV</code>:</p>
+<figure class="highlight"><pre><code class="language-text" data-lang="text">$ 
export BUILDR_ENV=production
+$ buildr
+(in /home/john/project, production)</code></pre></figure><p>Unless you tell it 
otherwise, Buildr assumes you&#8217;re developing and sets the environment to 
<code>development</code>.</p>
+<p>Here&#8217;s a simple example for handling different environments within 
the Buildfile:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="n">project</span> <span 
class="s1">&#39;db-module&#39;</span> <span class="k">do</span>
+  <span class="n">db</span> <span class="o">=</span> <span 
class="p">(</span><span class="no">Buildr</span><span class="o">.</span><span 
class="n">environment</span> <span class="o">==</span> <span 
class="s1">&#39;production&#39;</span> <span class="p">?</span> <span 
class="s1">&#39;oracle&#39;</span> <span class="p">:</span> <span 
class="s1">&#39;hsql&#39;</span><span class="p">)</span>
+  <span class="n">resources</span><span class="o">.</span><span 
class="n">from</span><span class="p">(</span><span class="n">_</span><span 
class="p">(</span><span class="s2">&quot;src/main/</span><span 
class="si">#{</span><span class="n">db</span><span class="si">}</span><span 
class="s2">&quot;</span><span class="p">))</span>
+<span class="k">end</span></code></pre></figure><p>We recommend picking a 
convention for your different environments and following it across all your 
projects.  For example:</p>
+<table>
+       <tr>
+               <th>Environment </th>
+               <th>Use when &#8230; </th>
+       </tr>
+       <tr>
+               <td> development   </td>
+               <td> Developing on your machine. </td>
+       </tr>
+       <tr>
+               <td> test          </td>
+               <td> Running in test environment, continuous integration. </td>
+       </tr>
+       <tr>
+               <td> production    </td>
+               <td> Building for release/production. </td>
+       </tr>
+</table>
+<h2 id="profiles">Profiles</h2>
+<p>Different environments may require different configurations, some you will 
want to control with code, others you will want to specify in the profiles 
file.</p>
+<p>The profiles file is a <span class="caps">YAML</span> file called 
<code>profiles.yaml</code> that you place in the same directory as the 
Buildfile.  We selected <span class="caps">YAML</span> because it&#8217;s 
easier to read and edit than <span class="caps">XML</span>.</p>
+<p>For example, to support three different database configurations, we could 
write:</p>
+<figure class="highlight"><pre><code class="language-yaml" 
data-lang="yaml"><span class="c1"># HSQL, don&#39;t bother storing to 
disk.</span>
+<span class="l-Scalar-Plain">development</span><span 
class="p-Indicator">:</span>
+  <span class="l-Scalar-Plain">db</span><span class="p-Indicator">:</span> 
<span class="l-Scalar-Plain">hsql</span>
+  <span class="l-Scalar-Plain">jdbc</span><span class="p-Indicator">:</span> 
<span class="l-Scalar-Plain">hsqldb:mem:devdb</span>
+
+<span class="c1"># Make sure we&#39;re not messing with bigstrong.</span>
+<span class="l-Scalar-Plain">test</span><span class="p-Indicator">:</span>
+  <span class="l-Scalar-Plain">db</span><span class="p-Indicator">:</span> 
<span class="l-Scalar-Plain">oracle</span>
+  <span class="l-Scalar-Plain">jdbc</span><span class="p-Indicator">:</span> 
<span class="l-Scalar-Plain">oracle:thin:@localhost:1521:test</span>
+
+<span class="c1"># The real deal.</span>
+<span class="l-Scalar-Plain">production</span><span 
class="p-Indicator">:</span>
+  <span class="l-Scalar-Plain">db</span><span class="p-Indicator">:</span> 
<span class="l-Scalar-Plain">oracle</span>
+  <span class="l-Scalar-Plain">jdbc</span><span class="p-Indicator">:</span> 
<span 
class="l-Scalar-Plain">oracle:thin:@bigstrong:1521:mighty</span></code></pre></figure><p>Here&#8217;s
 a simple example for a buildfile that uses the profile information:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="n">project</span> <span 
class="s1">&#39;db-module&#39;</span> <span class="k">do</span>
+  <span class="c1"># Copy SQL files specific for the database we&#39;re 
using,</span>
+  <span class="c1"># for example, everything under src/main/hsql.</span>
+  <span class="n">resources</span><span class="o">.</span><span 
class="n">from</span><span class="p">(</span><span class="n">_</span><span 
class="p">(</span><span class="s2">&quot;src/main/</span><span 
class="si">#{</span><span class="no">Buildr</span><span class="o">.</span><span 
class="n">settings</span><span class="o">.</span><span 
class="n">profile</span><span class="o">[</span><span 
class="s1">&#39;db&#39;</span><span class="o">]</span><span 
class="si">}</span><span class="s2">&quot;</span><span class="p">))</span>
+  <span class="c1"># Set the JDBC URL in copied resource files (config.xml 
needs this).</span>
+  <span class="n">resources</span><span class="o">.</span><span 
class="n">filter</span><span class="o">.</span><span class="n">using</span> 
<span class="ss">:jdbc</span><span class="o">=&gt;</span><span 
class="no">Buildr</span><span class="o">.</span><span 
class="n">settings</span><span class="o">.</span><span 
class="n">profile</span><span class="o">[</span><span 
class="s1">&#39;jdbc&#39;</span><span class="o">]</span>
+<span class="k">end</span></code></pre></figure><p>The <code>profile</code> 
method returns the current profile, selected based on the current <a 
href="#environments">environment</a>.  You can get a list of all profiles by 
calling <code>profiles</code>.</p>
+<p>When you run the above example in <code>development</code>, the current 
profile will return the hash <code>{ 'db'=&gt;'hsql', 
'jdbc'=&gt;'hsqldb:mem:devdb' }</code>.</p>
+<p>We recommend following conventions and using the same environments in all 
your projects, but sometimes the profiles end up being the same, so 
here&#8217;s a trick you can use to keep your profiles <span 
class="caps">DRY</span>.</p>
+<p><span class="caps">YAML</span> allows you to use anchors 
(<code>&amp;</code>), similar to ID attributes in <span 
class="caps">XML</span>, reference the anchored element (<code>*</code>) 
elsewhere, and merge one element into another (<code>&lt;&lt;</code>).  For 
example:</p>
+<figure class="highlight"><pre><code class="language-yaml" 
data-lang="yaml"><span class="c1"># We&#39;ll reference this one as 
common.</span>
+<span class="l-Scalar-Plain">development</span><span 
class="p-Indicator">:</span> <span class="nl">&amp;common</span>
+  <span class="l-Scalar-Plain">db</span><span class="p-Indicator">:</span> 
<span class="l-Scalar-Plain">hsql</span>
+  <span class="l-Scalar-Plain">jdbc</span><span class="p-Indicator">:</span> 
<span class="l-Scalar-Plain">hsqldb:mem:devdb</span>
+  <span class="l-Scalar-Plain">resources</span><span 
class="p-Indicator">:</span>
+    <span class="l-Scalar-Plain">copyright</span><span 
class="p-Indicator">:</span> <span class="l-Scalar-Plain">Me (C) 2008</span>
+<span class="c1"># Merge the values from common, override JDBC URL.</span>
+<span class="l-Scalar-Plain">test</span><span class="p-Indicator">:</span>
+  <span class="l-Scalar-Plain">&lt;&lt;</span><span 
class="p-Indicator">:</span> <span class="nv">*common</span>
+  <span class="l-Scalar-Plain">jdbc</span><span class="p-Indicator">:</span> 
<span 
class="l-Scalar-Plain">hsqldb:file:testdb</span></code></pre></figure><p>You 
can <a href="http://www.yaml.org";>learn more about <span 
class="caps">YAML</span> here</a>, and use this handy <a 
href="http://www.yaml.org/refcard.html";><span class="caps">YAML</span> quick 
reference</a>.</p>
+      </div>
+      <div id='footer'>Copyright &copy; 2007-2016 The Apache Software 
Foundation</div>
+    </div>
+  </body>
+</html>

Added: dev/buildr/1.5.0/site/testing.html
==============================================================================
--- dev/buildr/1.5.0/site/testing.html (added)
+++ dev/buildr/1.5.0/site/testing.html Sat Sep 17 06:23:20 2016
@@ -0,0 +1,185 @@
+<html>
+  <head>
+    <meta content='text/html;charset=UTF-8' http-equiv='Content-Type'>
+    <title>buildr &mdash; Testing</title>
+    <style type='text/css'>
+      @import 'css/default.css';
+      @import 'css/syntax.css';
+    </style>
+    <style media='print' type='text/css'>
+      @import 'css/print.css';
+    </style>
+    <meta content='Official Buildr documentation from the people in the know' 
name='subject'>
+    <link href='images/favicon.png' rel='shortcut icon'>
+  </head>
+  <body>
+    <div id='wrap'>
+      <div id='header'>
+        <a href='http://buildr.apache.org/' title="Build like you code"><img 
alt='buildr' src='images/buildr.png'></a>
+        <div class='tagline'>Build like you code</div>
+      </div>
+      <div id='pages'>
+        <ol class='toc'>
+          <li>Start Here
+            <ol class="toc">
+              <li><a href='index.html'>Welcome</a></li>
+              <li><a href='quick_start.html'>Quick Start</a></li>
+              <li><a href='installing.html'>Installing & Running</a></li>
+              <li><a 
href='http://cwiki.apache.org/confluence/display/BUILDR/Index'>Community 
Wiki</a></li>
+            </ol>
+          </li>
+          <li>Using Buildr
+            <ol class="toc">
+              <li><a href='buildr.pdf'>This Guide (PDF)</a></li>
+              <li><a href='projects.html'>Projects</a></li>
+              <li><a href='building.html'>Building</a></li>
+              <li><a href='artifacts.html'>Artifacts</a></li>
+              <li><a href='packaging.html'>Packaging</a></li>
+              <li><a href='testing.html'>Testing</a></li>
+              <li><a href='releasing.html'>Releasing</a></li>
+              <li><a href='settings_profiles.html'>Settings/Profiles</a></li>
+              <li><a href='languages.html'>Languages</a></li>
+              <li><a href='more_stuff.html'>More Stuff</a></li>
+              <li><a href='extending.html'>Extending Buildr</a></li>
+              <li><a 
href='http://cwiki.apache.org/confluence/display/BUILDR/Buildr+HowTos'>How-Tos</a></li>
+            </ol>
+          </li>
+          <li>Reference
+            <ol class="toc">
+              <li><a href='rdoc/Buildr.html'>API</a></li>
+              <li><a href='http://docs.rubyrake.org'>Rake</a></li>
+              <li><a href='https://rubygems.org/gems/Antwrap'>Antwrap</a></li>
+              <li><a 
href='http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions'>Troubleshooting</a></li>
+            </ol>
+          </li>
+          <li>Get Involved
+            <ol class="toc">
+              <li><a href='download.html'>Download</a></li>
+              <li><a href='mailing_lists.html'>Mailing Lists</a></li>
+              <li><a href='http://www.twitter.com/buildr'>Twitter</a></li>
+              <li><a 
href='http://issues.apache.org/jira/browse/Buildr'>Issues/Bugs</a></li>
+              <li><a href='https://builds.apache.org/view/A-F/view/Buildr'>CI 
Jobs</a></li>
+              <li><a href='contributing.html'>Contributing</a></li>
+            </ol>
+          </li>
+          <li>
+            <form action='http://www.google.com/' 
onsubmit="document.getElementById('gQuery').value += ' site:buildr.apache.org'">
+              <input name='q' size='20' type='text' id='gQuery'>
+              <input name='sa' type='submit' value='Search'>
+              <img alt='Google Custom Search' 
src='http://www.google.com/coop/images/google_custom_search_smnar.gif'>
+            </form>
+          </li>
+        </ol>
+      </div>
+      <div id='content'>
+        <h1 id='testing'>Testing</h1>
+        <ol class="toc"><li><a href="#writing">Writing Tests</a></li><li><a 
href="#ignoring">Excluding Tests and Ignoring Failures</a></li><li><a 
href="#running">Running Tests</a></li><li><a href="#integration">Integration 
Tests</a></li><li><a href="#setup_teardown">Using Setup and 
Teardown</a></li><li><a href="#checks">Testing Your Build</a></li><li><a 
href="#bdd">Behaviour-Driven Development</a></li></ol>
+        <p>Untested code is broken code, so we take testing seriously.  Off 
the bat you get to use either JUnit or TestNG for writing unit tests and 
integration tests. And you can also add your own framework, or even script 
tests using Ruby.  But first, let&#8217;s start with the basics.</p>
+<h2 id="writing">Writing Tests</h2>
+<p>Each project has a <code>TestTask</code> that you can access using the 
<code>test</code> method. <code>TestTask</code> reflects on the fact that each 
project has one task responsible for getting the tests to run and acting on the 
results.  But in fact there are several tasks that do all the work, and a 
<code>test</code> task coordinates all of that.</p>
+<p>The first two tasks to execute are <code>test.compile</code> and 
<code>test.resources</code>.  They work similar to <code>compile</code> and 
<code>resources</code>, but uses a different set of directories.  For example, 
Java tests compile from the <code>src/test/java</code> directory into the 
<code>target/test/classes</code> directory, while resources are copied from 
<code>src/test/resources</code> into <code>target/test/resources</code>.</p>
+<p>The <code>test.compile</code> task will run the <code>compile</code> task 
first, then use the same dependencies to compile the test classes.  That much 
you already assumed.  It also adds the test framework (e.g. JUnit, TestNG) and 
JMock to the dependency list.  Less work for you.</p>
+<p>If you need more dependencies, the best way to add them is by calling 
<code>test.with</code>.  This method adds dependencies to both 
<code>compile.dependencies</code> (for compiling) and 
<code>test.dependencies</code> (for running).  You can manage these two 
dependency lists separately, but using <code>test.with</code> is good enough in 
more cases.</p>
+<p>Once compiled, the <code>test</code> task runs all the tests.</p>
+<p>Different languages use different test frameworks.  You can find out more 
about available test frameworks in the <a href="languages.html">Languages</a> 
section.</p>
+<h2 id="ignoring">Excluding Tests and Ignoring Failures</h2>
+<p>If you have a lot of tests that are failing or just hanging there 
collecting dusts, you can tell Buildr to ignore them.  You can either tell 
Buildr to only run specific tests, for example:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="nb">test</span><span class="o">.</span><span 
class="n">include</span> <span 
class="s1">&#39;com.acme.tests.passing.*&#39;</span></code></pre></figure><p>Or 
tell it to exclude specific tests, for example:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="nb">test</span><span class="o">.</span><span 
class="n">exclude</span> <span class="s1">&#39;*FailingTest&#39;</span><span 
class="p">,</span> <span 
class="s1">&#39;*FailingWorseTest&#39;</span></code></pre></figure><p>Note that 
we&#8217;re always using the package qualified class name, and you can use star 
(<code>*</code>) to substitute for any set of characters.</p>
+<p>When tests fail, Buildr fails the <code>test</code> task.  This is usually 
a good thing, but you can also tell Buildr to ignore failures by resetting the 
<code>:fail_on_failure</code> option:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="nb">test</span><span class="o">.</span><span 
class="n">using</span> <span class="ss">:fail_on_failure</span><span 
class="o">=&gt;</span><span 
class="kp">false</span></code></pre></figure><p>Besides giving you a free pass 
to ignore failures, you can use it for other causes, for example, as a gentle 
reminder:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="nb">test</span> <span class="k">do</span>
+  <span class="nb">warn</span> <span class="s2">&quot;Did you forget 
something?&quot;</span> <span class="k">if</span> <span 
class="nb">test</span><span class="o">.</span><span class="n">tests</span><span 
class="o">.</span><span class="n">nil?</span> <span class="o">||</span> <span 
class="nb">test</span><span class="o">.</span><span class="n">tests</span><span 
class="o">.</span><span class="n">empty?</span>
+<span class="k">end</span></code></pre></figure><p>The <code>tests</code> 
collection holds the names of all classes with tests, if any. And there&#8217;s 
<code>classes</code>, which holds the names of all test classes.  We&#8217;ll 
let you imagine creative use for these two.</p>
+<h2 id="running">Running Tests</h2>
+<p>It&#8217;s a good idea to run tests every time you change the source code, 
so we wired the <code>build</code> task to run the <code>test</code> task at 
the end of the build.  And conveniently enough, the <code>build</code> task is 
the default task, so another way to build changes in your code and run your 
tests:</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span>buildr</code></pre></figure><p>That only works with the 
local <code>build</code> task and any local task that depends on it, like 
<code>package</code>, <code>install</code> and <code>upload</code>.  Each 
project also has its own <code>build</code> task that does not invoke the 
<code>test</code> task, so <code>buildr build</code> will run the tests cases, 
but <code>buildr foo:build</code> will not.</p>
+<p>While it&#8217;s a good idea to always run your tests, it&#8217;s not 
always possible. There are two ways you can get <code>build</code> to not run 
the <code>test</code> task.  You can set the environment variable 
<code>test</code> to <code>no</code> (but <code>skip</code> and 
<code>off</code> will also work). You can do that when running Buildr:</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span>buildr <span class="nb">test</span><span 
class="o">=</span>no</code></pre></figure><p>Or set it once in your 
environment:</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span><span class="nb">export </span><span 
class="nv">TEST</span><span class="o">=</span>no
+<span class="nv">$ </span>buildr</code></pre></figure><p>If you&#8217;re 
feeling really adventurous, you can also disable tests from your Buildfile or 
<code>buildr.rb</code> file, by setting <code>options.test = false</code>. We 
didn&#8217;t say it&#8217;s a good idea, we&#8217;re just giving you the 
option.</p>
+<p>The <code>test</code> task is just smart enough to run all the tests it 
finds, but will accept include/exclude patterns.  Often enough you&#8217;re 
only working on one broken test and you only want to run that one test.  Better 
than changing your Buildfile, you can run the <code>test</code> task with a 
pattern.  For example:</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span>buildr <span 
class="nb">test</span>:KillerAppTest</code></pre></figure><p>Buildr will then 
run only tests that match the pattern <code>KillerAppTest</code>.  It uses 
pattern matching, so <code>test:Foo</code> will run 
<code>com.acme.FooTest</code> and <code>com.acme.FooBarTest</code>.  With Java, 
you can use this to pick a class name, or a package name to run all tests in 
that package, or any such combination.  In fact, you can specify several 
patterns separated with commas.  For example:</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span>buildr <span 
class="nb">test</span>:FooTest,BarTest</code></pre></figure><p>Buildr 
forcefully runs all tests that match the pattern.  If you want to re-run all 
tests even if your sources have not changed, you can execute:</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span>buildr <span 
class="nb">test</span>:*</code></pre></figure><p>You can exclude tests by 
preceeding them with a minus sign (&#8216;-&#8217;):</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span>buildr <span 
class="nb">test</span>:-Bar</code></pre></figure><p>The above would run all 
tests except those with a name containing <code>Bar</code>.  Exclusions can be 
combined with inclusions:</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span>buildr <span 
class="nb">test</span>:Foo,-Bar</code></pre></figure><p>Buildr would then run 
tests with names containing <code>Foo</code> but not <code>Bar</code>.</p>
+<p>As you probably noticed, Buildr will stop your build at the first test that 
fails.  We think it&#8217;s a good idea, except when it&#8217;s not.  If 
you&#8217;re using a continuous build system, you&#8217;ll want a report of all 
the failed tests without stopping at the first failure.  To make that happen, 
set the environment variable <code>test</code> to &#8220;all&#8221;, or the 
Buildr <code>options.test</code> option to <code>:all</code>.  For example:</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span>buildr package <span class="nb">test</span><span 
class="o">=</span>all</code></pre></figure><p>We&#8217;re using 
<code>package</code> and not <code>build</code> above.  When using a continuous 
build system, you want to make sure that packages are created, contain the 
right files, and also run the integration tests.</p>
+<p>During development, if you want to re-run only tests that have failed 
during the last test execution, you can execute:</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span>buildr <span 
class="nb">test</span>:failed</code></pre></figure><p>One last note on running 
tests.  By default when you run tests, Buildr will automatically run all 
transitive test dependencies.  This mean if you run &#8220;buildr test&#8221; 
inside project <code>bar</code> and <code>bar</code> depends on project 
<code>foo</code>, Buildr will first run tests in project <code>foo</code> if 
there have been any changes affecting <code>foo</code> that haven&#8217;t been 
taken into account yet.   This behavior often surprises people, especially when 
they are trying to get things done and only care about tests in 
<code>bar</code> at that moment.  For those times when you&#8217;d like to 
focus your testing on specific projects, Buildr has the <code>only</code> 
option that will only run tests for projects specified on the command line,</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span>buildr <span class="nb">test</span><span 
class="o">=</span>only bar:test</code></pre></figure><h2 
id="integration">Integration Tests</h2>
+<p>So far we talked about unit tests.  Unit tests are run in isolation on the 
specific project they test, in an isolated environment, generally with minimal 
setup and teardown.  You get a sense of that when we told you tests run after 
the <code>build</code> task, and include JMock in the dependency list.</p>
+<p>In contrast, integration tests are run with a number of components, in an 
environment that resembles production, often with more complicates setup and 
teardown procedures.  In this section we&#8217;ll talk about the differences 
between running unit and integration tests.</p>
+<p>You write integration tests much the same way as you write unit tests, 
using <code>test.compile</code> and <code>test.resources</code>.  However, you 
need to tell Buildr that your tests will execute during integration test.  To 
do so, add the following line in your project definition:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="nb">test</span><span class="o">.</span><span 
class="n">using</span> <span 
class="ss">:integration</span></code></pre></figure><p>Typically you&#8217;ll 
use unit tests in projects that create internal modules, such as JARs, and 
integration tests in projects that create components, such as WARs and EARs.  
You only need to use the <code>:integration</code> option with the later.</p>
+<p>To run integration tests on the current project:</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span>buildr integration</code></pre></figure><p>You can also run 
specific tests cases, for example:</p>
+<figure class="highlight"><pre><code class="language-sh" data-lang="sh"><span 
class="nv">$ </span>buildr integration:ClientTest</code></pre></figure><p>If 
you run the <code>package</code> task (or any task that depends on it, like 
<code>install</code> and <code>upload</code>), Buildr will first run the 
<code>build</code> task and all its unit tests, and then create the packages 
and run the integration tests.  That gives you full coverage for your tests and 
ready to release packages.  As with unit tests, you can set the environment 
variable <code>test</code> to &#8220;no&#8221; to skip integration tests, or 
&#8220;all&#8221; to ignore failures.</p>
+<h2 id="setup_teardown">Using Setup and Teardown</h2>
+<p>Some tests need you to setup an environment before they run, and tear it 
down afterwards.  The test frameworks (JUnit, TestNG) allow you to do that for 
each test.  Buildr provides two additional mechanisms for dealing with more 
complicated setup and teardown procedures.</p>
+<p>Integration tests run a setup task before the tests, and a teardown task 
afterwards.  You can use this task to setup a Web server for testing your Web 
components, or a database server for testing persistence.  You can access 
either task by calling <code>integration.setup</code> and 
<code>integration.teardown</code>.  For example:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="n">integration</span><span 
class="o">.</span><span class="n">setup</span> <span class="p">{</span> <span 
class="n">server</span><span class="o">.</span><span class="n">start</span> 
<span class="p">;</span> <span class="n">server</span><span 
class="o">.</span><span class="n">deploy</span> <span class="p">}</span>
+<span class="n">integration</span><span class="o">.</span><span 
class="n">teardown</span> <span class="p">{</span> <span 
class="n">server</span><span class="o">.</span><span class="n">stop</span> 
<span class="p">}</span></code></pre></figure><p>Depending on your build, you 
may want to enhance the setup/teardown tasks from within a project, for 
example, to populate the database with data used by that project&#8217;s test, 
or from outside the project definition, for example, to start and stop the Web 
server.</p>
+<p>Likewise, each project has its own setup and teardown tasks that are run 
before and after tests for that specific project.  You can access these tasks 
using <code>test.setup</code> and <code>test.teardown</code>.</p>
+<h2 id="checks">Testing Your Build</h2>
+<p>So you got the build running and all the tests pass, binaries are shipping 
when you find out some glaring omissions.  The license file is empty, the 
localized messages for Japanese are missing, the <span class="caps">CSS</span> 
files are not where you expect them to be.  The fact is, some errors slip by 
unit and integration tests.  So how do we make sure the same mistake 
doesn&#8217;t happen again?</p>
+<p>Each project has a <code>check</code> task that runs just after packaging.  
You can use this task to verify that your build created the files you wanted it 
to create. And to make it extremely convenient, we introduced the notion of 
expectations.</p>
+<p>You use the <code>check</code> method to express and expectation.  Buildr 
will then run all these expectations against your project, and fail at the 
first expectation that doesn&#8217;t match.  An expectation says three things.  
Let&#8217;s look at a few examples:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="n">check</span> <span 
class="n">package</span><span class="p">(</span><span 
class="ss">:war</span><span class="p">),</span> <span class="s1">&#39;should 
exist&#39;</span> <span class="k">do</span>
+  <span class="n">it</span><span class="o">.</span><span 
class="n">should</span> <span class="n">exist</span>
+<span class="k">end</span>
+<span class="n">check</span> <span class="n">package</span><span 
class="p">(</span><span class="ss">:war</span><span class="p">),</span> <span 
class="s1">&#39;should contain a manifest&#39;</span> <span class="k">do</span>
+  <span class="n">it</span><span class="o">.</span><span 
class="n">should</span> <span class="n">contain</span><span 
class="p">(</span><span class="s1">&#39;META-INF/MANIFEST.MF&#39;</span><span 
class="p">)</span>
+<span class="k">end</span>
+<span class="n">check</span> <span class="n">package</span><span 
class="p">(</span><span class="ss">:war</span><span class="p">)</span><span 
class="o">.</span><span class="n">path</span><span class="p">(</span><span 
class="s1">&#39;WEB-INF&#39;</span><span class="p">),</span> <span 
class="s1">&#39;should contain files&#39;</span> <span class="k">do</span>
+  <span class="n">it</span><span class="o">.</span><span 
class="n">should_not</span> <span class="n">be_empty</span>
+<span class="k">end</span>
+<span class="n">check</span> <span class="n">package</span><span 
class="p">(</span><span class="ss">:war</span><span class="p">)</span><span 
class="o">.</span><span class="n">path</span><span class="p">(</span><span 
class="s1">&#39;WEB-INF/classes&#39;</span><span class="p">),</span> <span 
class="s1">&#39;should contain classes&#39;</span> <span class="k">do</span>
+  <span class="n">it</span><span class="o">.</span><span 
class="n">should</span> <span class="n">contain</span><span 
class="p">(</span><span class="s1">&#39;**/*.class&#39;</span><span 
class="p">)</span>
+<span class="k">end</span>
+<span class="n">check</span> <span class="n">package</span><span 
class="p">(</span><span class="ss">:war</span><span class="p">)</span><span 
class="o">.</span><span class="n">entry</span><span class="p">(</span><span 
class="s1">&#39;META-INF/MANIFEST&#39;</span><span class="p">),</span> <span 
class="s1">&#39;should have license&#39;</span> <span class="k">do</span>
+  <span class="n">it</span><span class="o">.</span><span 
class="n">should</span> <span class="n">contain</span><span 
class="p">(</span><span class="sr">/Copyright (C) 2007/</span><span 
class="p">)</span>
+<span class="k">end</span>
+<span class="n">check</span> <span class="n">file</span><span 
class="p">(</span><span class="s1">&#39;target/classes&#39;</span><span 
class="p">),</span> <span class="s1">&#39;should contain class 
files&#39;</span> <span class="k">do</span>
+  <span class="n">it</span><span class="o">.</span><span 
class="n">should</span> <span class="n">contain</span><span 
class="p">(</span><span class="s1">&#39;**/*.class&#39;</span><span 
class="p">)</span>
+<span class="k">end</span>
+<span class="n">check</span> <span class="n">file</span><span 
class="p">(</span><span 
class="s1">&#39;target/classes/killerapp/Code.class&#39;</span><span 
class="p">),</span> <span class="s1">&#39;should exist&#39;</span> <span 
class="k">do</span>
+  <span class="n">it</span><span class="o">.</span><span 
class="n">should</span> <span class="n">exist</span>
+<span class="k">end</span></code></pre></figure><p>The first argument is the 
subject, or the project if you skip the first argument.  The second argument is 
the description, optional, but we recommend using it.  The method 
<code>it</code> returns the subject.</p>
+<p>You can also write the first expectation like this:</p>
+<figure class="highlight"><pre><code class="language-ruby" 
data-lang="ruby"><span class="n">check</span> <span class="k">do</span>
+  <span class="n">package</span><span class="p">(</span><span 
class="ss">:jar</span><span class="p">)</span><span class="o">.</span><span 
class="n">should</span> <span class="n">exist</span>
+<span class="k">end</span></code></pre></figure><p>We recommend using the 
subject and description, they make your build easier to read and maintain, and 
produce better error messages.</p>
+<p>There are two methods you can call on just about any object, called 
<code>should</code> and <code>should_not</code>.  Each method takes an 
argument, a matcher, and executes that matcher.  If the matcher returns false, 
<code>should</code> fails.  You can figure out what <code>should_not</code> 
does in the same case.</p>
+<p>Buildr provides the following matchers:</p>
+<table>
+       <tr>
+               <th>Method </th>
+               <th>Checks that &#8230; </th>
+       </tr>
+       <tr>
+               <td> <code>exist</code>   </td>
+               <td> Given a file task checks that the file (or directory) 
exists. </td>
+       </tr>
+       <tr>
+               <td> <code>empty</code>   </td>
+               <td> Given a file task checks that the file (or directory) is 
empty. </td>
+       </tr>
+       <tr>
+               <td> <code>contain</code> </td>
+               <td> Given a file task referencing a file, checks its contents, 
using string or regular expression.  For a file task referencing a directory, 
checks that it contains the specified files; global patterns using 
<code>*</code> and <code>**</code> are allowed. </td>
+       </tr>
+</table>
+<p>All these matchers operate against a file task.  If you run them against a 
ZipTask (including <span class="caps">JAR</span>, <span 
class="caps">WAR</span>, etc) or a TarTask, they can also check the contents of 
the archive.  And as you can see in the examples above, you can also run them 
against a path in an archive, checking its contents as if it was a directory, 
or against an entry in an archive, checking the content of that file.</p>
+<p class="note">The <code>package</code> method returns a package task based 
on packaging type, identifier, group, version and classifier.  The last four 
are inferred, but if you create a package with different specifications (for 
example, you specify a classifier) your checks must call <code>package</code> 
with the same qualifying arguments to return the very same package task.</p>
+<p>Buildr expectations are based on RSpec.  <a 
href="http://rspec.info/";>RSpec</a> is the behavior-driven development 
framework we use to test Buildr itself.  Check the RSpec documentation if want 
to see all the supported matchers, or want to write your own.</p>
+<h2 id="bdd">Behaviour-Driven Development</h2>
+<p>Buildr supports several Behaviour-Driven Development(<span 
class="caps">BDD</span>) frameworks for testing your projects.  Buildr follows 
each framework naming conventions, searching for files under the 
<code>src/spec/{lang}</code> directory.</p>
+<p>You can learn more about each <span class="caps">BDD</span> framework in 
the <a href="languages.html">Languages</a> section.</p>
+<p>Next, let&#8217;s talk about <a href="settings_profiles.html">customizing 
your environment and using profiles</a></p>
+      </div>
+      <div id='footer'>Copyright &copy; 2007-2016 The Apache Software 
Foundation</div>
+    </div>
+  </body>
+</html>


Reply via email to