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/11/09 02:20:58 UTC
svn commit: r1540236 [2/7] - in /buildr/site: ./ rdoc/ rdoc/Buildr/
rdoc/Buildr/ArchiveTask/ rdoc/Buildr/Assets/ rdoc/Buildr/IntellijIdea/
rdoc/Rake/ rdoc/js/
Modified: buildr/site/extending.html
URL: http://svn.apache.org/viewvc/buildr/site/extending.html?rev=1540236&r1=1540235&r2=1540236&view=diff
==============================================================================
--- buildr/site/extending.html (original)
+++ buildr/site/extending.html Sat Nov 9 01:20:57 2013
@@ -79,7 +79,7 @@
</ol>
</div>
<div id='content'>
- <h1 id='extending buildr'>Extending Buildr</h1>
+ <h1 id='Liquid error: wrong number of arguments (1 for 2)'>Extending Buildr</h1>
<ol class="toc"><li><a href="#tasks">Organizing Tasks</a></li><li><a href="#extensions">Creating Extensions</a></li><li><a href="#layouts">Using Alternative Layouts</a></li></ol>
<h2 id="tasks">Organizing Tasks</h2>
<p>A couple of things we learned while working on Buildr. Being able to write your own Rake tasks is a very powerful feature. But if you find yourself doing the same thing over and over, you might also want to consider functions. They give you a lot more power and easy abstractions.</p>
@@ -94,22 +94,26 @@
<span class="n">ant</span><span class="p">(</span><span class="s1">'openjpa'</span><span class="p">)</span> <span class="k">do</span> <span class="o">|</span><span class="n">ant</span><span class="o">|</span>
<span class="n">ant</span><span class="o">.</span><span class="n">taskdef</span> <span class="ss">:name</span><span class="o">=></span><span class="s1">'mapping'</span><span class="p">,</span>
<span class="ss">:classname</span><span class="o">=></span><span class="s1">'org.apache.openjpa.jdbc.ant.MappingToolTask'</span><span class="p">,</span>
- <span class="ss">:classpath</span><span class="o">=></span><span class="no">REQUIRES</span><span class="o">.</span><span class="n">join</span><span class="p">(</span><span class="ss">File</span><span class="p">:</span><span class="ss">:PATH_SEPARATOR</span><span class="p">)</span>
+ <span class="ss">:classpath</span><span class="o">=></span><span class="no">REQUIRES</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="no">PATH_SEPARATOR</span><span class="p">)</span>
<span class="n">ant</span><span class="o">.</span><span class="n">mapping</span> <span class="ss">:schemaAction</span><span class="o">=></span><span class="s1">'build'</span><span class="p">,</span> <span class="ss">:sqlFile</span><span class="o">=></span><span class="n">task</span><span class="o">.</span><span class="n">name</span><span class="p">,</span>
<span class="ss">:ignoreErrors</span><span class="o">=></span><span class="kp">true</span> <span class="k">do</span>
<span class="n">ant</span><span class="o">.</span><span class="n">config</span> <span class="ss">:propertiesFile</span><span class="o">=></span><span class="n">_</span><span class="p">(</span><span class="s1">'src/main/sql/derby.xml'</span><span class="p">)</span>
<span class="n">ant</span><span class="o">.</span><span class="n">classpath</span> <span class="ss">:path</span><span class="o">=></span><span class="n">projects</span><span class="p">(</span><span class="s1">'store'</span><span class="p">,</span> <span class="s1">'utils'</span> <span class="p">)</span><span class="o">.</span>
- <span class="n">flatten</span><span class="o">.</span><span class="n">map</span><span class="p">(</span><span class="o">&</span><span class="ss">:to_s</span><span class="p">)</span><span class="o">.</span><span class="n">join</span><span class="p">(</span><span class="ss">File</span><span class="p">:</span><span class="ss">:PATH_SEPARATOR</span><span class="p">)</span>
+ <span class="n">flatten</span><span class="o">.</span><span class="n">map</span><span class="p">(</span><span class="o">&</span><span class="ss">:to_s</span><span class="p">)</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="no">PATH_SEPARATOR</span><span class="p">)</span>
<span class="k">end</span>
<span class="k">end</span>
<span class="k">end</span>
-</code></pre></div><p>To this:</p>
+</code></pre>
+</div>
+<p>To this:</p>
<div class="highlight"><pre><code class="ruby"><span class="n">file</span><span class="p">(</span><span class="s1">'derby.sql'</span><span class="p">)</span> <span class="k">do</span>
<span class="n">mapping_tool</span> <span class="ss">:action</span><span class="o">=></span><span class="s1">'build'</span><span class="p">,</span> <span class="ss">:sql</span><span class="o">=></span><span class="n">task</span><span class="o">.</span><span class="n">name</span><span class="p">,</span>
<span class="ss">:properties</span><span class="o">=></span><span class="n">_</span><span class="p">(</span><span class="s1">'src/main/sql/derby.xml'</span><span class="p">),</span>
<span class="ss">:classpath</span><span class="o">=></span><span class="n">projects</span><span class="p">(</span><span class="s1">'store'</span><span class="p">,</span> <span class="s1">'utils'</span><span class="p">)</span>
<span class="k">end</span>
-</code></pre></div><p>I prefer the second. It’s easier to look at the Buildfile and understand what it does. It’s easier to maintain when you only have to look at the important information.</p>
+</code></pre>
+</div>
+<p>I prefer the second. It’s easier to look at the Buildfile and understand what it does. It’s easier to maintain when you only have to look at the important information.</p>
<p>But just using functions is not always enough. You end up with a Buildfile containing a lot of code that clearly doesn’t belong there. For starters, I recommend putting it in the <code>tasks</code> directory. Write it into a file with a <code>.rake</code> extension and place that in the <code>tasks</code> directory next to the Buildfile. Buildr will automatically pick it up and load it for you.</p>
<p>If you want to share these pre-canned definitions between projects, you have a few more options. You can share the <code>tasks</code> directory using <span class="caps">SVN</span> externals, Git modules, or whichever cross-repository feature your source control system supports. Another mechanism with better version control is to package all these tasks, functions and modules into a <a href="http://rubygems.org/">Gem</a> and require it from your Buildfile. You can run your own internal Gem server for that.</p>
<p>To summarize, there are several common ways to distribute extensions:</p>
@@ -128,11 +132,15 @@
<div class="highlight"><pre><code class="ruby"><span class="k">class</span> <span class="nc">Project</span>
<span class="kp">include</span> <span class="no">MyExtension</span>
<span class="k">end</span>
-</code></pre></div><p>You can also extend a given project instance and only that instance by extending it with the module:</p>
+</code></pre>
+</div>
+<p>You can also extend a given project instance and only that instance by extending it with the module:</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="kp">extend</span> <span class="no">MyExtension</span>
<span class="k">end</span>
-</code></pre></div><p>Some extensions require tighter integration with the project, specifically for setting up tasks and properties, or for configuring tasks based on the project definition. You can do that by adding callbacks to the process.</p>
+</code></pre>
+</div>
+<p>Some extensions require tighter integration with the project, specifically for setting up tasks and properties, or for configuring tasks based on the project definition. You can do that by adding callbacks to the process.</p>
<p>The easiest way to add callbacks is by incorporating the Extension module in your own extension, and using the various class methods to define callback behavior.</p>
<table>
<tr>
@@ -194,7 +202,9 @@
<span class="k">class</span> <span class="nc">Buildr</span><span class="o">::</span><span class="no">Project</span>
<span class="kp">include</span> <span class="no">LinesOfCode</span>
<span class="k">end</span>
-</code></pre></div><p>You may find interesting that this Extension <span class="caps">API</span> is used pervasively inside Buildr itself. Many of the standard tasks such as <code>compile</code>, <code>test</code>, <code>package</code> are extensions to a very small core.</p>
+</code></pre>
+</div>
+<p>You may find interesting that this Extension <span class="caps">API</span> is used pervasively inside Buildr itself. Many of the standard tasks such as <code>compile</code>, <code>test</code>, <code>package</code> are extensions to a very small core.</p>
<p>Starting with Buildr 1.4, it’s possible to define ordering between <code>before_define</code> and <code>after_define</code> code blocks in a way similar to Rake’s dependencies. For example, if you wanted to override <code>project.test.compile.from</code> in <code>after_define</code>, you could do so by in</p>
<div class="highlight"><pre><code class="ruby"><span class="n">after_define</span><span class="p">(</span><span class="ss">:functional_tests</span><span class="p">)</span> <span class="k">do</span> <span class="o">|</span><span class="n">project</span><span class="o">|</span>
<span class="c1"># Change project.test.compile.from if it's not already pointing</span>
@@ -208,21 +218,29 @@
<span class="c1"># make sure project.test.compile.from is updated before the</span>
<span class="c1"># compile extension picks up its value</span>
<span class="n">after_define</span><span class="p">(</span><span class="ss">:compile</span> <span class="o">=></span> <span class="ss">:functional_test</span><span class="p">)</span>
-</code></pre></div><p>Core extensions provide the following named callbacks: <code>compile</code>, <code>test</code>, <code>build</code>, <code>package</code> and <code>check</code>.</p>
+</code></pre>
+</div>
+<p>Core extensions provide the following named callbacks: <code>compile</code>, <code>test</code>, <code>build</code>, <code>package</code> and <code>check</code>.</p>
<h2 id="layouts">Using Alternative Layouts</h2>
<p>Buildr follows a common convention for project layouts: Java source files appear in <code>src/main/java</code> and compile to <code>target/classes</code>, resources are copied over from <code>src/main/resources</code> and so forth. Not all projects follow this convention, so it’s now possible to specify an alternative project layout.</p>
<p>The default layout is available in <code>Layout.default</code>, and all projects inherit it. You can set <code>Layout.default</code> to your own layout, or define a project with a given layout (recommended) by setting the <code>:layout</code> property. Projects inherit the layout from their parent projects. For example:</p>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s1">'foo'</span><span class="p">,</span> <span class="ss">:layout</span><span class="o">=></span><span class="n">my_layout</span> <span class="k">do</span>
<span class="o">.</span><span class="n">.</span><span class="o">.</span>
<span class="k">end</span>
-</code></pre></div><p>A layout is an object that implements the <code>expand</code> method. The easiest way to define a custom layout is to create a new <code>Layout</code> object and specify mapping between names used by Buildr and actual paths within the project. For example:</p>
+</code></pre>
+</div>
+<p>A layout is an object that implements the <code>expand</code> method. The easiest way to define a custom layout is to create a new <code>Layout</code> object and specify mapping between names used by Buildr and actual paths within the project. For example:</p>
<div class="highlight"><pre><code class="ruby"><span class="n">my_layout</span> <span class="o">=</span> <span class="no">Layout</span><span class="o">.</span><span class="n">new</span>
<span class="n">my_layout</span><span class="o">[</span><span class="ss">:source</span><span class="p">,</span> <span class="ss">:main</span><span class="p">,</span> <span class="ss">:java</span><span class="o">]</span> <span class="o">=</span> <span class="s1">'java'</span>
<span class="n">my_layout</span><span class="o">[</span><span class="ss">:source</span><span class="p">,</span> <span class="ss">:main</span><span class="p">,</span> <span class="ss">:resources</span><span class="o">]</span> <span class="o">=</span> <span class="s1">'resources'</span>
-</code></pre></div><p>Partial expansion also works, so you can specify the above layout using:</p>
+</code></pre>
+</div>
+<p>Partial expansion also works, so you can specify the above layout using:</p>
<div class="highlight"><pre><code class="ruby"><span class="n">my_layout</span> <span class="o">=</span> <span class="no">Layout</span><span class="o">.</span><span class="n">new</span>
<span class="n">my_layout</span><span class="o">[</span><span class="ss">:source</span><span class="p">,</span> <span class="ss">:main</span><span class="o">]</span> <span class="o">=</span> <span class="s1">''</span>
-</code></pre></div><p>If you need anything more complex, you can always subclass <code>Layout</code> and add special handling in the <code>expand</code> method, you’ll find one such example in the <span class="caps">API</span> documentation.</p>
+</code></pre>
+</div>
+<p>If you need anything more complex, you can always subclass <code>Layout</code> and add special handling in the <code>expand</code> method, you’ll find one such example in the <span class="caps">API</span> documentation.</p>
<p>The built-in tasks expand lists of symbols into relative paths, using the following convention:</p>
<table>
<tr>
@@ -268,7 +286,8 @@
<span class="c1"># This will work with different layouts.</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">include</span> <span class="n">path_to</span><span class="p">(</span><span class="ss">:source</span><span class="p">,</span> <span class="ss">:main</span><span class="p">,</span> <span class="ss">:etc</span><span class="p">,</span> <span class="s1">'*'</span><span class="p">)</span>
<span class="k">end</span>
-</code></pre></div>
+</code></pre>
+</div>
</div>
<div id='footer'>Copyright © 2007-2010 The Apache Software Foundation</div>
</div>
Modified: buildr/site/index.html
URL: http://svn.apache.org/viewvc/buildr/site/index.html?rev=1540236&r1=1540235&r2=1540236&view=diff
==============================================================================
--- buildr/site/index.html (original)
+++ buildr/site/index.html Sat Nov 9 01:20:57 2013
@@ -79,7 +79,7 @@
</ol>
</div>
<div id='content'>
- <h1 id='apache buildr'>Apache Buildr</h1>
+ <h1 id='Liquid error: wrong number of arguments (1 for 2)'>Apache Buildr</h1>
<ol class="toc"><li><a href="#why">Why Buildr Rocks</a></li><li><a href="#what">What You Get</a></li><li><a href="#news">What’s New</a></li><li><a href="#notices">Credits & Notices</a></li></ol>
<p>Apache Buildr is a build system for Java-based applications, including support for Scala, Groovy and a growing number of <span class="caps">JVM</span> languages and tools. We wanted something that’s simple and intuitive to use, so we only need to tell it what to do, and it takes care of the rest. But also something we can easily extend for those one-off tasks, with a language that’s a joy to use. And of course, we wanted it to be fast, reliable and have outstanding dependency management.</p>
<h2 id="why">Why Buildr Rocks</h2>
@@ -118,6 +118,28 @@
</ul>
<p>So let’s get started. You can <a href="quick_start.html">read the documentation online</a>, or <a href="buildr.pdf">download the <span class="caps">PDF</span></a>.</p>
<h2 id="news">What’s New</h2>
+<p>Highlights from Buildr 1.4.15 (2013-11-06)</p>
+<ul>
+ <li>Change: Updated the ‘test_jar’ package type to have a<br />
+ classifier of ‘tests’ and thus match maven<br />
+ conventions. Reported by Chris Bozic.</li>
+ <li>Fixed: <span class="caps">BUILDR</span>-689 – Ensure that war file includes generated<br />
+ assets rather than the “source” assets that may have<br />
+ been filtered.</li>
+ <li>Fixed: <span class="caps">BUILDR</span>-689 – Define assets task before the project is<br />
+ defined to avoid “undefined method `project=’” if the<br />
+ project attempts to generate into the same directory.</li>
+ <li>Added: <span class="caps">BUILDR</span>-679 – Support uploading to a snapshot repository<br />
+ defined by repositories.snapshot_to if the artifact is<br />
+ a snapshot. Submitted by Tammo van Lessen.</li>
+ <li>Change: Update the default output directory used in the jaxb_xjc<br />
+ addon to use Maven conventions.</li>
+ <li>Fixed: Bug in IdeaProject.partition_dependencies resulted in<br />
+ projects being rebuilt if artifacts were added to the<br />
+ project with dependencies on the current project.</li>
+ <li>Fixed: <span class="caps">BUILDR</span>-605 – Ensure package task invokes included paths.</li>
+ <li>Fixed: <span class="caps">BUILDR</span>-609 – compile.from should accept Task argument.</li>
+</ul>
<p>Highlights from Buildr 1.4.14 (2013-10-11)</p>
<ul>
<li>Fixed: Fixed regression in gwt addon.</li>
Modified: buildr/site/installing.html
URL: http://svn.apache.org/viewvc/buildr/site/installing.html?rev=1540236&r1=1540235&r2=1540236&view=diff
==============================================================================
--- buildr/site/installing.html (original)
+++ buildr/site/installing.html Sat Nov 9 01:20:57 2013
@@ -79,7 +79,7 @@
</ol>
</div>
<div id='content'>
- <h1 id='installing and running'>Installing and Running</h1>
+ <h1 id='Liquid error: wrong number of arguments (1 for 2)'>Installing and Running</h1>
<ol class="toc"><li><a href="#linux">Installing on Linux</a></li><li><a href="#osx">Installing on OS X</a></li><li><a href="#windows">Installing on Windows</a></li><li><a href="#jruby">Installing for JRuby</a></li><li>Using multiple versions of Buildr</li><li><a href="#running">Running Buildr</a></li><li><a href="#help">Help Tasks</a></li><li><a href="#more">Learning More</a></li></ol>
<h1 id="all-in-one">All In One Bundle</h1>
<p>Contributors to this project maintain a separate distribution over on <a href="http://rubyforge.org/projects/buildr">RubyForge</a>. Using this distribution, it is possible to install Buildr just like you would install Apache Ant or Apache Maven. It comes bundled with JRuby and distributed as a cross-platform zip or tar.gz file.</p>
@@ -103,47 +103,71 @@
<p>On <strong>RedHat/Fedora</strong> you can use yum to install Ruby and RubyGems, and then upgrade to the most recent version of RubyGems:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>sudo yum install ruby rubygems ruby-devel gcc
<span class="nv">$ </span>sudo gem update --system
-</code></pre></div><p>On <strong>Ubuntu</strong> you have to install several packages:</p>
+</code></pre>
+</div>
+<p>On <strong>Ubuntu</strong> you have to install several packages:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>sudo apt-get install ruby-full ruby1.8-dev libopenssl-ruby build-essential
-</code></pre></div><p>If using Ubuntu 9.10 or earlier, the Debian package for <code>rubygems</code> will not allow you to install Buildr, so you need to install RubyGems from source:</p>
+</code></pre>
+</div>
+<p>If using Ubuntu 9.10 or earlier, the Debian package for <code>rubygems</code> will not allow you to install Buildr, so you need to install RubyGems from source:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz
<span class="nv">$ </span>tar xzf rubygems-1.3.1.tgz
<span class="nv">$ </span><span class="nb">cd </span>rubygems-1.3.1
<span class="nv">$ </span>sudo ruby setup.rb
<span class="nv">$ </span>sudo ln -s /usr/bin/gem1.8 /usr/bin/gem
-</code></pre></div><p>Before installing Buildr, please set the <code>JAVA_HOME</code> environment variable to point to your <span class="caps">JDK</span> distribution. Next, use Ruby Gem to install Buildr:</p>
+</code></pre>
+</div>
+<p>Before installing Buildr, please set the <code>JAVA_HOME</code> environment variable to point to your <span class="caps">JDK</span> distribution. Next, use Ruby Gem to install Buildr:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>sudo env <span class="nv">JAVA_HOME</span><span class="o">=</span><span class="nv">$JAVA_HOME</span> gem install buildr
-</code></pre></div><p>To upgrade to a new version or install a specific version:</p>
+</code></pre>
+</div>
+<p>To upgrade to a new version or install a specific version:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>sudo env <span class="nv">JAVA_HOME</span><span class="o">=</span><span class="nv">$JAVA_HOME</span> gem update buildr
<span class="nv">$ </span>sudo env <span class="nv">JAVA_HOME</span><span class="o">=</span><span class="nv">$JAVA_HOME</span> gem install buildr -v 1.4.3
-</code></pre></div><h2 id="osx">Installing on OS X</h2>
+</code></pre>
+</div>
+<h2 id="osx">Installing on OS X</h2>
<p><strong>The easy way:</strong> Use this script to <a href="scripts/install-osx.sh">install Buildr on OS X</a>. This script will install the most recent version of Buildr, or if already installed, upgrade to the most recent version. It will also install Ruby 1.8.6 if not already installed (using MacPorts/Fink) and upgrage RubyGems to 1.3.1 or later.</p>
<p>You need to have the Apple Development Tools installed. They are available on the Mac <span class="caps">OSX</span> installation CD.</p>
<p class="note">Java Update 3 for Snow Leopard removes header files necessary to compile the native Ruby-Java Bridge (<span class="caps">RJB</span>) gem, so installing rjb gem may fail on OS X. The solution is to install Java for Mac OS X 10.6 Update 3 Developer Package from http://connect.apple.com before <code>gem install</code>.</p>
<p><strong>Using <span class="caps">RVM</span>?</strong> If you’re not using the built-in ruby on OS X (e.g., if you’re using <span class="caps">RVM</span>), you’ll need to force-install the platform-independent <span class="caps">RJB</span>:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>gem install rjb -v 1.3.3 --platform ruby
-</code></pre></div><p>The darwin pre-built binary seems to only work with the built-in ruby.</p>
+</code></pre>
+</div>
+<p>The darwin pre-built binary seems to only work with the built-in ruby.</p>
<p><br></p>
<p><strong>In details:</strong> OS X 10.5 (Leopard) comes with a recent version of Ruby 1.8.6. You do not need to install a different version of Ruby when running OS X 10.5.</p>
<p>OS X 10.4 (Tiger) includes an older version of Ruby that is not compatible with Buildr. You can install Ruby 1.8.6 using MacPorts (<code>sudo port install ruby rb-rubygems</code>), Fink or the <a href="http://rubyosx.rubyforge.org/">Ruby One-Click Installer for OS X</a>.</p>
<p>We recommend you first upgrade to the latest version of Ruby gems:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>sudo gem update --system
-</code></pre></div><p>Before installing Buildr, please set the <code>JAVA_HOME</code> environment variable to point to your <span class="caps">JDK</span> distribution:</p>
+</code></pre>
+</div>
+<p>Before installing Buildr, please set the <code>JAVA_HOME</code> environment variable to point to your <span class="caps">JDK</span> distribution:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span><span class="nb">export </span><span class="nv">JAVA_HOME</span><span class="o">=</span>/Library/Java/Home
-</code></pre></div><p>To install Buildr:</p>
+</code></pre>
+</div>
+<p>To install Buildr:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>sudo env <span class="nv">JAVA_HOME</span><span class="o">=</span><span class="nv">$JAVA_HOME</span> gem install buildr
-</code></pre></div><p>To upgrade to a new version or install a specific version:</p>
+</code></pre>
+</div>
+<p>To upgrade to a new version or install a specific version:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>sudo env <span class="nv">JAVA_HOME</span><span class="o">=</span><span class="nv">$JAVA_HOME</span> gem update buildr
<span class="nv">$ </span>sudo env <span class="nv">JAVA_HOME</span><span class="o">=</span><span class="nv">$JAVA_HOME</span> gem install buildr -v 1.3.4
-</code></pre></div><h2 id="windows">Installing on Windows</h2>
+</code></pre>
+</div>
+<h2 id="windows">Installing on Windows</h2>
<p><strong>The easy way:</strong> The easiest way to install Ruby is using the <a href="http://rubyinstaller.rubyforge.org/">one-click installer</a>. Be sure to install Ruby 1.8.6; support for Ruby 1.9.x is still a work in progress. Once installed, set the <code>JAVA_HOME</code> environment variable and run <code>gem install buildr --platform mswin32</code>.</p>
<p><br></p>
<p><strong>In details:</strong> Before installing Buildr, please set the <code>JAVA_HOME</code> environment variable to point to your <span class="caps">JDK</span> distribution. Next, use Ruby Gem to install Buildr:</p>
<div class="highlight"><pre><code class="sh">> gem install buildr --platform mswin32
-</code></pre></div><p>To upgrade to a new version or install a specific version:</p>
+</code></pre>
+</div>
+<p>To upgrade to a new version or install a specific version:</p>
<div class="highlight"><pre><code class="sh">> gem update buildr
> gem install buildr -v 1.3.4 --platform mswin32
-</code></pre></div><h2 id="jruby">Installing for JRuby</h2>
+</code></pre>
+</div>
+<h2 id="jruby">Installing for JRuby</h2>
<p><strong>The easy way:</strong> Use this bash script to <a href="scripts/install-jruby.sh">install Buildr on JRuby</a>. This script will install the most recent version of Buildr, or if already installed, upgrade to the most recent version. If necessary, it will also install JRuby 1.6.1 in <code>/opt/jruby</code> and update the <code>PATH</code> variable in <code>~/.bash_profile</code> or <code>~/.profile</code>.</p>
<p><br></p>
<p><strong>In details:</strong> If you don’t already have JRuby 1.5.1 or later installed, you can download it from the <a href="http://www.jruby.org/download">JRuby site</a>.</p>
@@ -151,13 +175,19 @@
<p>For Linux and OS X:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span><span class="nb">export </span><span class="nv">PATH</span><span class="o">=</span><span class="nv">$PATH</span>:<span class="o">[</span>path to JRuby<span class="o">]</span>/bin:<span class="nv">$JAVA_HOME</span>/bin
<span class="nv">$ </span>jruby -S gem install buildr
-</code></pre></div><p>For Windows:</p>
+</code></pre>
+</div>
+<p>For Windows:</p>
<div class="highlight"><pre><code class="sh">> <span class="nb">set </span><span class="nv">PATH</span><span class="o">=</span>%PATH%;<span class="o">[</span>path to JRuby<span class="o">]</span>/bin;%JAVA_HOME%/bin
> jruby -S gem install buildr
-</code></pre></div><p>To upgrade to a new version or install a specific version:</p>
+</code></pre>
+</div>
+<p>To upgrade to a new version or install a specific version:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>jruby -S gem update buildr
<span class="nv">$ </span>jruby -S gem install buildr -v 1.3.4
-</code></pre></div><p><strong>Important: Running JRuby and Ruby side by side</strong></p>
+</code></pre>
+</div>
+<p><strong>Important: Running JRuby and Ruby side by side</strong></p>
<p>Ruby and JRuby maintain separate Gem repositories, and in fact install slightly different versions of the Buildr Gem (same functionality, different dependencies). Installing Buildr for Ruby does not install it for JRuby and vice versa.</p>
<p>If you have JRuby installed but not Ruby, the <code>gem</code> and <code>buildr</code> commands will use JRuby. If you have both JRuby and Ruby installed, follow the instructions below. To find out if you have Ruby installed (some operating systems include it by default), run <code>ruby --version</code> from the command line.</p>
<p>To work exclusively with JRuby, make sure it shows first on the path, for example, by setting <code>PATH=/opt/jruby/bin:$PATH</code>.</p>
@@ -168,19 +198,25 @@
<span class="nv">$ </span><span class="c"># with JRuby</span>
<span class="nv">$ </span>jruby -S gem install buildr
<span class="nv">$ </span>jruby -S buildr
-</code></pre></div><p>Run <code>buildr --version</code> from the command line to find which version of Buildr you are using by default. If you see <code>(JRuby ...)</code>, Buildr is running on that version of JRuby.</p>
+</code></pre>
+</div>
+<p>Run <code>buildr --version</code> from the command line to find which version of Buildr you are using by default. If you see <code>(JRuby ...)</code>, Buildr is running on that version of JRuby.</p>
<h2>Using multiple versions of Buildr</h2>
<p>Rubygems makes it possible to install several versions of Buildr side-by-side on the same system. If you want to run a specific version, you can do so by adding the version number between underscores (‘_’) as the first command-line parameter. For example,</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr _1.3.4_ clean <span class="c"># runs Buildr v1.3.4</span>
<span class="nv">$ </span>buildr _1.4.4_ clean <span class="c"># runs Buildr v1.4.4</span>
-</code></pre></div><p class="note">There are two `buildr` executables installed by Rubygems. One script serves to select the specified (or default) version of Buildr and is typically found under `/usr/bin/buildr` or `/var/lib/gems/1.8/bin/buildr`. The exact location will vary depending on your system. The other script is the Buildr bootstrap per se and can be found under the specific version of Buildr, e.g, `/var/lib/gems/1.8/gems/buildr-1.4.0/bin/buildr`. The first script should be on your `<span class="caps">PATH</span>`. The second script should not be called directly and should not be on your `<span class="caps">PATH</span>`.</p>
+</code></pre>
+</div>
+<p class="note">There are two `buildr` executables installed by Rubygems. One script serves to select the specified (or default) version of Buildr and is typically found under `/usr/bin/buildr` or `/var/lib/gems/1.8/bin/buildr`. The exact location will vary depending on your system. The other script is the Buildr bootstrap per se and can be found under the specific version of Buildr, e.g, `/var/lib/gems/1.8/gems/buildr-1.4.0/bin/buildr`. The first script should be on your `<span class="caps">PATH</span>`. The second script should not be called directly and should not be on your `<span class="caps">PATH</span>`.</p>
<h2 id="running">Running Buildr</h2>
<p>You need a <strong>Buildfile</strong>, a build script that tells Buildr all about the projects it’s building, what they contain, what to produce, and so on. The Buildfile resides in the root directory of your project. We’ll talk more about it in <a href="projects.html">the next chapter</a>. If you don’t already have one, ask Buildr to create it by running <code>buildr</code>.</p>
<p class="tip">You’ll notice that Buildr creates a file called <code>buildfile</code>. It’s case sensitive, but Buildr will look for either <code>buildfile</code> or <code>Buildfile</code>.</p>
<p>You use Buildr by running the <code>buildr</code> command:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr <span class="o">[</span>options<span class="o">]</span> <span class="o">[</span>tasks<span class="o">]</span> <span class="o">[</span><span class="nv">name</span><span class="o">=</span>value<span class="o">]</span>
-</code></pre></div><p>There are several options you can use, for a full list of options type <code>buildr --help</code>:</p>
+</code></pre>
+</div>
+<p>There are several options you can use, for a full list of options type <code>buildr --help</code>:</p>
<table>
<tr>
<th>Option </th>
@@ -232,22 +268,30 @@
buildr clean build
<span class="c"># Package and install</span>
buildr install
-</code></pre></div><p>If you don’t specify a task, Buildr will run the <a href="building.html"><code>build</code> task</a>, compiling source code and running test cases. Running a task may run other tasks as well, for example, running the <code>install</code> task will also run <code>package</code>.</p>
+</code></pre>
+</div>
+<p>If you don’t specify a task, Buildr will run the <a href="building.html"><code>build</code> task</a>, compiling source code and running test cases. Running a task may run other tasks as well, for example, running the <code>install</code> task will also run <code>package</code>.</p>
<p>There are several <a href="settings_profiles.html#env_vars">environment variables</a> that let you control how Buildr works, for example, to skip test cases during a build, or specify options for the <span class="caps">JVM</span>. Depending on the variable, you may want to set it once in your environment, or set a different value each time you run Buildr.</p>
<p>For example:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span><span class="nb">export </span><span class="nv">JAVA_OPTS</span><span class="o">=</span><span class="s1">'-Xms1g -Xmx1g'</span>
<span class="nv">$ </span>buildr <span class="nv">TEST</span><span class="o">=</span>no
-</code></pre></div><h2 id="help">Help Tasks</h2>
+</code></pre>
+</div>
+<h2 id="help">Help Tasks</h2>
<p>Buildr includes a number of informative tasks. Currently that number stands at two, but we’ll be adding more tasks in future releases. These tasks report information from the Buildfile, so you need one to run them. For more general help (version number, command line arguments, etc) use <code>buildr --help</code>.</p>
<p>To start with, type:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr <span class="nb">help</span>
-</code></pre></div><p>You can list the name and description of all your projects using the <code>help:projects</code> task. For example:</p>
+</code></pre>
+</div>
+<p>You can list the name and description of all your projects using the <code>help:projects</code> task. For example:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr <span class="nb">help</span>:projects
killer-app <span class="c"># Code. Build. ??? Profit!</span>
killer-app:teh-api <span class="c"># Abstract classes and interfaces</span>
killer-app:teh-impl <span class="c"># All those implementation details</span>
killer-app:la-web <span class="c"># What our users see</span>
-</code></pre></div><p>You are, of course, describing your projects for the sake of those who will maintain your code, right? To describe a project, or a task, call the <code>desc</code> method before the project or task definition.</p>
+</code></pre>
+</div>
+<p>You are, of course, describing your projects for the sake of those who will maintain your code, right? To describe a project, or a task, call the <code>desc</code> method before the project or task definition.</p>
<p>So next let’s talk about <a href="projects.html">projects</a>.</p>
<h2 id="more">Learning More</h2>
<p><strong>Ruby</strong> It pays to pick up Ruby as a second (or first) programming language. It’s fun, powerful and slightly addictive. If you’re interested in learning Ruby the language, a good place to start is <a href="http://www.pragprog.com/titles/ruby/programming-ruby">Programming Ruby: The Pragmatic Programmer’s Guide</a>, fondly known as the <em>Pickaxe book</em>.</p>
Modified: buildr/site/languages.html
URL: http://svn.apache.org/viewvc/buildr/site/languages.html?rev=1540236&r1=1540235&r2=1540236&view=diff
==============================================================================
--- buildr/site/languages.html (original)
+++ buildr/site/languages.html Sat Nov 9 01:20:57 2013
@@ -79,7 +79,7 @@
</ol>
</div>
<div id='content'>
- <h1 id='languages'>Languages</h1>
+ <h1 id='Liquid error: wrong number of arguments (1 for 2)'>Languages</h1>
<ol class="toc"><li><a href="#java">Java</a></li><li><a href="#scala">Scala</a></li><li><a href="#groovy">Groovy</a></li><li><a href="#ruby">Ruby</a></li></ol>
<h2 id="java">Java</h2>
<h3>Compiling Java</h3>
@@ -154,7 +154,9 @@
</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>
@@ -177,14 +179,20 @@
<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>
@@ -203,12 +211,16 @@
</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>
@@ -225,10 +237,14 @@
</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>
@@ -238,7 +254,9 @@
<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>
@@ -246,17 +264,27 @@
<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>
@@ -326,7 +354,9 @@
</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>
@@ -334,15 +364,23 @@
<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>
@@ -351,16 +389,24 @@
<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>
@@ -370,7 +416,9 @@
<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>
@@ -389,7 +437,9 @@
<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>
@@ -403,7 +453,9 @@
<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>
@@ -414,7 +466,9 @@
<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>
@@ -435,10 +489,14 @@
<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>
@@ -448,7 +506,9 @@
<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>
@@ -456,16 +516,22 @@
<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>
@@ -540,7 +606,9 @@
<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>
@@ -562,7 +630,9 @@ 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>
@@ -572,7 +642,9 @@ 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>
@@ -580,7 +652,9 @@ 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>
@@ -589,12 +663,16 @@ 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>
Modified: buildr/site/mailing_lists.html
URL: http://svn.apache.org/viewvc/buildr/site/mailing_lists.html?rev=1540236&r1=1540235&r2=1540236&view=diff
==============================================================================
--- buildr/site/mailing_lists.html (original)
+++ buildr/site/mailing_lists.html Sat Nov 9 01:20:57 2013
@@ -79,7 +79,7 @@
</ol>
</div>
<div id='content'>
- <h1 id='mailing lists'>Mailing Lists</h1>
+ <h1 id='Liquid error: wrong number of arguments (1 for 2)'>Mailing Lists</h1>
<ol class="toc"></ol>
<form action="http://buildr.markmail.org/search/">Search all Buildr archives: <input type="text" name="q" size="50"/> <input type="submit" value="Search"/></form><p><br/></p>
<table>