You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@buildr.apache.org by do...@apache.org on 2013/10/06 09:17:12 UTC
svn commit: r1529576 [4/18] - in /buildr/site: ./ rdoc/ rdoc/Benchmark/
rdoc/Buildr/ rdoc/Buildr/ArchiveTask/ rdoc/Buildr/ArtifactNamespace/
rdoc/Buildr/Assets/ rdoc/Buildr/Checks/ rdoc/Buildr/Cobertura/
rdoc/Buildr/Cobertura/CoberturaExtension/ rdoc/B...
Modified: buildr/site/more_stuff.html
URL: http://svn.apache.org/viewvc/buildr/site/more_stuff.html?rev=1529576&r1=1529575&r2=1529576&view=diff
==============================================================================
--- buildr/site/more_stuff.html (original)
+++ buildr/site/more_stuff.html Sun Oct 6 07:17:05 2013
@@ -96,35 +96,23 @@ scala> </pre>
<p>Unfortunately, for such a tool to be useful in Java, Scala or Groovy development, it must have access to the <code>CLASSPATH</code>, not only the compiled project binaries, but also its full list of dependencies. While it is usually possible with such tools to specify the classpath upon startup (e.g. the <code>-cp</code> switch for the Scala shell), this can get extremely tedious for project’s with more dependencies, especially when some of these dependencies are defined using <code>transitive</code> artifacts.</p>
<p>Buildr is capable of easing this workflow by providing full support for the configuration and launch of interactive shells, the relevant shell may be launched simply by invoking the <code>shell</code> task:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr shell
-</code></pre>
-</div>
-<p>The <code>shell</code> task depends upon <code>compile</code>, meaning that any changed source files will be recompiled prior to the shell’s launch. Tests will not be run, nor will test files be recompiled. From within the shell itself, you should have access to your project’s compilation classpath (anything specified using <code>compile.with</code>) as well as the compiled sources for your project.</p>
+</code></pre></div><p>The <code>shell</code> task depends upon <code>compile</code>, meaning that any changed source files will be recompiled prior to the shell’s launch. Tests will not be run, nor will test files be recompiled. From within the shell itself, you should have access to your project’s compilation classpath (anything specified using <code>compile.with</code>) as well as the compiled sources for your project.</p>
<p>The project classpath is determined by checking the current working directory of your system shell (the path from which the <code>buildr shell</code> command was invoked) and recursively finding the relevant project for that directory. Thus, if you have a parent project <code>foo</code> which has sub-projects <code>bar</code> and <code>baz</code>, you may invoke an interactive shell for the <code>baz</code> project simply by <code>cd</code>-ing into its project directory (or any of its sub-directories) and invoking the <code>shell</code> task. You may also invoke a shell against a specific project by giving its fully-qualified descriptor as a prefix to the <code>shell</code> task:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr foo:bar:shell
-</code></pre>
-</div>
-<h3>Supported Shells</h3>
+</code></pre></div><h3>Supported Shells</h3>
<p>By default, Buildr will open the interactive shell which corresponds to your project’s language. Thus, if your project is using Groovy, it will invoke the <code>groovysh</code> command, configured with the appropriate classpath. If your project is using Scala, then the <code>shell</code> task will invoke the <code>scala</code> command. Unfortunately, the Java language does not define an interactive shell of any kind, however for those projects using exclusively the Java language, Buildr will use the <a href="http://www.beanshell.org/manual/quickstart.html#The_BeanShell_GUI">BeanShell</a> console.</p>
<p>However, you may still wish to exploit the advantages of an interactive shell from some other <span class="caps">JVM</span> language even while working in Java. Alternatively, you may want to use some shell other than the default even when working in a language which has its own. There are two ways to acheive this aim. The quickest way is to explicitly specify the relevant shell at the call-site:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr foo:shell:jirb
-</code></pre>
-</div>
-<p>This will open the <span class="caps">JIRB</span> shell (the JRuby <span class="caps">REPL</span>) for the <code>foo</code> project. Whenever you are specifying a shell explicitly in this fashion, you <strong>must</strong> fully-qualify the project name:</p>
+</code></pre></div><p>This will open the <span class="caps">JIRB</span> shell (the JRuby <span class="caps">REPL</span>) for the <code>foo</code> project. Whenever you are specifying a shell explicitly in this fashion, you <strong>must</strong> fully-qualify the project name:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr shell:jirb <span class="c"># wrong!!</span>
-</code></pre>
-</div>
-<p>The above will fail because of the way that Rake tasks are dispatched.</p>
+</code></pre></div><p>The above will fail because of the way that Rake tasks are dispatched.</p>
<p>Obviously, this explicit specification is a little bit clunky. It would be much easier if we could simply say that we <strong>always</strong> want to use the <span class="caps">JIRB</span> shell for this particular project. This can be done by using the <code>shell.using</code> directive within your project definition:</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">shell</span><span class="o">.</span><span class="n">using</span> <span class="ss">:jirb</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>With this project definition, we can now invoke the <code>shell</code> task and <span class="caps">JIRB</span> will be launched, regardless of the default for our project’s language:</p>
+</code></pre></div><p>With this project definition, we can now invoke the <code>shell</code> task and <span class="caps">JIRB</span> will be launched, regardless of the default for our project’s language:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr shell
-</code></pre>
-</div>
-<p>Buildr supports several different shell providers, and the framework is flexible enough that additional support can be added almost trivially. The following table gives the complete list of supported shells, their corresponding <code>shell.using</code> descriptor and the language for which they are the default (if applicable):</p>
+</code></pre></div><p>Buildr supports several different shell providers, and the framework is flexible enough that additional support can be added almost trivially. The following table gives the complete list of supported shells, their corresponding <code>shell.using</code> descriptor and the language for which they are the default (if applicable):</p>
<table>
<tr>
<th>Shell Name </th>
@@ -162,22 +150,14 @@ scala> </pre>
<p>By default, Buildr is moderately verbose, meaning that it attempts to give you enough context into what’s happening during the build.</p>
<p>It’s possible to silence Buildr if you’re inconvenienced by its default verbosity by issuing,</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr --silent
-</code></pre>
-</div>
-<p>On the other hand, if you want Buildr to give you more context in order to trace what’s happening, you can use the <code>-t</code> options:</p>
+</code></pre></div><p>On the other hand, if you want Buildr to give you more context in order to trace what’s happening, you can use the <code>-t</code> options:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr -t
-</code></pre>
-</div>
-<p>Using <code>-t</code> will also display backtraces if and when they occur.</p>
+</code></pre></div><p>Using <code>-t</code> will also display backtraces if and when they occur.</p>
<p>Many components can be individually configured to display more output if you’re debugging a specific area of your build. For instance, you could use <code>--trace=javac,groovyc</code> to enable tracing of the Java and Groovy compilers:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr --trace<span class="o">=</span>javac,groovyc
-</code></pre>
-</div>
-<p>If you don’t know which tracing category you need to enable or if you want a full firehose worth of traces, you can enable all traces:</p>
+</code></pre></div><p>If you don’t know which tracing category you need to enable or if you want a full firehose worth of traces, you can enable all traces:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr --trace<span class="o">=</span>all
-</code></pre>
-</div>
-<h3 id="javarebel">JavaRebel Integration</h3>
+</code></pre></div><h3 id="javarebel">JavaRebel Integration</h3>
<p><a href="http://www.zeroturnaround.com/javarebel">JavaRebel</a> is a live bytecode reloading solution by Zero Turnaround. It’s a lot like the hot code reload feature found in many Java <span class="caps">IDE</span> debuggers (like Eclipse and IntelliJ), but capable of handling things like member addition or removal and new class definition. The tool itself is commercial and works with any <span class="caps">JVM</span> language, but they do offer a free license for use with Scala classes only.</p>
<p>If available, Buildr will use JavaRebel when configuring the launch for each interactive shell. Shells launched with JavaRebel integration will automatically receive recompiled changes on the fly without any need to restart the shell. There are some limitations to this which are specific to the shell in question, but for the most part, things Just Work.</p>
<p>JavaRebel auto-magical integration is done by searching for a valid JavaRebel install path in the following list of environment variables (in order):</p>
@@ -216,28 +196,18 @@ scala> </pre>
<span class="n">compile</span><span class="o">.</span><span class="n">with</span> <span class="no">COMMONS_IO</span><span class="p">,</span> <span class="no">HTTPCLIENT</span>
<span class="n">run</span><span class="o">.</span><span class="n">using</span> <span class="ss">:main</span> <span class="o">=></span> <span class="s2">"org.example.Main"</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>And then run,</p>
+</code></pre></div><p>And then run,</p>
<div class="highlight"><pre><code class="ruby"><span class="o">~</span><span class="sr">/my-project$ buildr run</span>
-</code></pre>
-</div>
-<p>which would launch your application using the project’s compile classpath.</p>
+</code></pre></div><p>which would launch your application using the project’s compile classpath.</p>
<p>It’s also possible to pass arguments to the <span class="caps">JVM</span> using the <code>:java_args</code> option:</p>
<div class="highlight"><pre><code class="ruby"> <span class="n">run</span><span class="o">.</span><span class="n">using</span> <span class="ss">:main</span> <span class="o">=></span> <span class="s2">"org.example.Main"</span><span class="p">,</span>
<span class="ss">:java_args</span> <span class="o">=></span> <span class="o">[</span><span class="s2">"-server"</span><span class="o">]</span>
-</code></pre>
-</div>
-<p>If your application requires arguments, you can pass in an array of values for the <code>:main</code> option, or provide a set of system properties using <code>:properties</code>.</p>
+</code></pre></div><p>If your application requires arguments, you can pass in an array of values for the <code>:main</code> option, or provide a set of system properties using <code>:properties</code>.</p>
<div class="highlight"><pre><code class="ruby"> <span class="n">run</span><span class="o">.</span><span class="n">using</span> <span class="ss">:main</span> <span class="o">=></span> <span class="o">[</span><span class="s2">"org.example.Main"</span><span class="p">,</span> <span class="s2">"-t"</span><span class="p">,</span> <span class="s2">"input.txt"</span><span class="o">]</span><span class="p">,</span>
<span class="ss">:properties</span> <span class="o">=></span> <span class="p">{</span> <span class="ss">:debug</span> <span class="o">=></span> <span class="s2">"true"</span> <span class="p">}</span>
-</code></pre>
-</div>
-<p>The <code>run</code> task is a local task, which means that Buildr will automatically pick the <code>run</code> task matching the project in the current directory. Executing the following command:</p>
+</code></pre></div><p>The <code>run</code> task is a local task, which means that Buildr will automatically pick the <code>run</code> task matching the project in the current directory. Executing the following command:</p>
<div class="highlight"><pre><code class="ruby"><span class="o">~</span><span class="sr">/my-project/su</span><span class="n">bproject</span><span class="err">$</span> <span class="n">buildr</span> <span class="n">run</span>
-</code></pre>
-</div>
-<p>will run the <code>my-project:subproject:run</code> task, assuming <code>my-project</code> is your top-level project.</p>
+</code></pre></div><p>will run the <code>my-project:subproject:run</code> task, assuming <code>my-project</code> is your top-level project.</p>
<p>Here is a summary of <code>run.using</code> options,</p>
<table>
<tr>
@@ -277,9 +247,7 @@ scala> </pre>
<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>
-</code></pre>
-</div>
-<p>Gems contain executable code, and for that reason Buildr will not install gems without your permission. When you run a build that includes any dependencies that are not already installed on your machine, Buildr will ask for permission before installing them. On Unix-based operating systems, you will also need sudo privileges and will be asked for your password before proceeding.</p>
+</code></pre></div><p>Gems contain executable code, and for that reason Buildr will not install gems without your permission. When you run a build that includes any dependencies that are not already installed on your machine, Buildr will ask for permission before installing them. On Unix-based operating systems, you will also need sudo privileges and will be asked for your password before proceeding.</p>
<p>Since this step requires your input, it will only happen when running Buildr interactively from the command line. In all other cases, Buildr will fail and report the missing dependencies. If you have an automated build environment, make sure to run the build once manually to install all the necessary dependencies.</p>
<p>When installing a gem for the first time, Buildr will automatically look for the latest available version. You can specify a particular version number, or a set of version numbers known to work with that build. You can use equality operations to specify a range of versions, for example, <code>1.2.3</code> to install only version 1.2.3, and <code>=> 1.2.3</code> to install version 1.2.3 or later.</p>
<p>You can also specify a range up to one version bump, for example, <code>~> 1.2.3</code> is the same as <code>>= 1.2.3 < 1.3.0</code>, and <code>~> 1.2</code> is the same as <code>>= 1.2.0 < 2.0.0</code>. If necessary, you can exclude a particular version number, for example, <code>~> 1.2.3 != 1.2.7</code>.</p>
@@ -287,9 +255,7 @@ scala> </pre>
<p>Most gems include documentation that you can access in several forms. You can use the <code>ri</code> command line tool to find out more about a class, module or specific method. For example:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>ri Buildr::Jetty
<span class="nv">$ </span>ri Buildr::Jetty.start
-</code></pre>
-</div>
-<p>You can also access documentation from a Web browser by running <code>gem server</code> and pointing your browser to <a href="http://localhost:8808">http://localhost:8808</a>. Note that after installing a new gem, you will need to restart the gem server to see its documentation.</p>
+</code></pre></div><p>You can also access documentation from a Web browser by running <code>gem server</code> and pointing your browser to <a href="http://localhost:8808">http://localhost:8808</a>. Note that after installing a new gem, you will need to restart the gem server to see its documentation.</p>
<h2 id="java">Using Java Libraries</h2>
<p>Buildr runs along side a <span class="caps">JVM</span>, using either <span class="caps">RJB</span> or JRuby. The Java module allows you to access Java classes and create Java objects.</p>
<p>Java classes are accessed as static methods on the <code>Java</code> module, for example:</p>
@@ -299,15 +265,11 @@ scala> </pre>
<span class="no">Java</span><span class="o">.</span><span class="n">java</span><span class="o">.</span><span class="n">lang</span><span class="o">.</span><span class="n">String</span><span class="o">.</span><span class="n">isInstance</span><span class="p">(</span><span class="n">str</span><span class="p">)</span>
<span class="o">=></span> <span class="kp">true</span>
<span class="no">Java</span><span class="o">.</span><span class="n">com</span><span class="o">.</span><span class="n">sun</span><span class="o">.</span><span class="n">tools</span><span class="o">.</span><span class="n">javac</span><span class="o">.</span><span class="n">Main</span><span class="o">.</span><span class="n">compile</span><span class="p">(</span><span class="n">args</span><span class="p">)</span>
-</code></pre>
-</div>
-<p>The <code>classpath</code> attribute allows Buildr to add JARs and directories to the classpath, for example, we use it to load Ant and various Ant tasks, code generators, test frameworks, and so forth.</p>
+</code></pre></div><p>The <code>classpath</code> attribute allows Buildr to add JARs and directories to the classpath, for example, we use it to load Ant and various Ant tasks, code generators, test frameworks, and so forth.</p>
<p>When using an artifact specification, Buildr will automatically download and install the artifact before adding it to the classpath.</p>
<p>For example, Ant is loaded as follows:</p>
<div class="highlight"><pre><code class="ruby"><span class="no">Java</span><span class="o">.</span><span class="n">classpath</span> <span class="o"><<</span> <span class="s1">'org.apache.ant:ant:jar:1.7.0'</span>
-</code></pre>
-</div>
-<p>Artifacts can only be downloaded after the Buildfile has loaded, giving it a chance to specify which remote repositories to use, so adding to classpath does not by itself load any libraries. You must call <code>Java.load</code> before accessing any Java classes to give Buildr a chance to load the libraries specified in the classpath.</p>
+</code></pre></div><p>Artifacts can only be downloaded after the Buildfile has loaded, giving it a chance to specify which remote repositories to use, so adding to classpath does not by itself load any libraries. You must call <code>Java.load</code> before accessing any Java classes to give Buildr a chance to load the libraries specified in the classpath.</p>
<p>When building an extension, make sure to follow these rules:</p>
<ol>
<li>Add to the <code>classpath</code> when the extension is loaded (i.e. in module or class definition), so the first call to <code>Java.load</code> anywhere in the code will include the libraries you specify.</li>
@@ -319,21 +281,15 @@ scala> </pre>
<p>Buildr provides an addon that allows you start a <a href="http://www.ruby-doc.org/stdlib/libdoc/drb/rdoc/index.html">dRuby</a> server hosting a buildfile, so that you can later invoke tasks on it without having to load the complete buildr runtime again.</p>
<p>Usage:</p>
<div class="highlight"><pre><code class="sh">buildr -r buildr/drb drb:start
-</code></pre>
-</div>
-<p>To stop the BuildrServer simply use Ctrl+C or kill the process.</p>
+</code></pre></div><p>To stop the BuildrServer simply use Ctrl+C or kill the process.</p>
<p>Once the server has been started you can invoke tasks using a simple script:</p>
<div class="highlight"><pre><code class="ruby"><span class="c1">#!/usr/bin/env ruby</span>
<span class="nb">require</span> <span class="s1">'rubygems'</span>
<span class="nb">require</span> <span class="s1">'buildr/drb'</span>
-<span class="no">Buildr</span><span class="o">::</span><span class="no">DRbApplication</span><span class="o">.</span><span class="n">run</span>
-</code></pre>
-</div>
-<p>Save this script as <code>dbuildr</code>, make it executable and use it to invoke tasks.</p>
+<span class="ss">Buildr</span><span class="p">:</span><span class="ss">:DRbApplication</span><span class="o">.</span><span class="n">run</span>
+</code></pre></div><p>Save this script as <code>dbuildr</code>, make it executable and use it to invoke tasks.</p>
<notextile><div class="highlight"><pre><code class="sh"><span class="nv">$ </span>dbuildr clean compile
-</code></pre>
-</div>
-<p></notextile></p>
+</code></pre></div><p></notextile></p>
<p>The <code>dbuildr</code> command will start the BuildrServer if there isn’t one already running. Subsequent calls to dbuildr will act as the client and invoke the tasks you provide to the server. If the buildfile has been modified it will be reloaded on the BuildrServer.</p>
<h2 id="notifications">Notifications: Growl, Libnotify, Qube</h2>
<p>Buildr support sending notifications when the build completes or fails, such as displaying the outcome message in an overlaid window on top of other applications.</p>
@@ -346,8 +302,8 @@ scala> </pre>
</ul>
<p>Here is an example using these extension points to send notifications using <a href="http://launchpad.net/qube">Qube</a>:</p>
<div class="highlight"><pre><code class="ruby"><span class="c1"># Send notifications using Qube</span>
-<span class="n">notify</span> <span class="o">=</span> <span class="nb">lambda</span> <span class="k">do</span> <span class="o">|</span><span class="nb">type</span><span class="p">,</span> <span class="n">title</span><span class="p">,</span> <span class="n">message</span><span class="o">|</span>
- <span class="n">param</span> <span class="o">=</span> <span class="k">case</span> <span class="nb">type</span>
+<span class="n">notify</span> <span class="o">=</span> <span class="nb">lambda</span> <span class="k">do</span> <span class="o">|</span><span class="n">type</span><span class="p">,</span> <span class="n">title</span><span class="p">,</span> <span class="n">message</span><span class="o">|</span>
+ <span class="n">param</span> <span class="o">=</span> <span class="k">case</span> <span class="n">type</span>
<span class="k">when</span> <span class="s1">'completed'</span><span class="p">;</span> <span class="s1">'-i'</span>
<span class="k">when</span> <span class="s1">'failed'</span><span class="p">;</span> <span class="s1">'-e'</span>
<span class="k">else</span> <span class="s1">'-i'</span>
@@ -361,49 +317,35 @@ scala> </pre>
<span class="no">Buildr</span><span class="o">.</span><span class="n">application</span><span class="o">.</span><span class="n">on_failure</span> <span class="k">do</span> <span class="o">|</span><span class="n">title</span><span class="p">,</span> <span class="n">message</span><span class="p">,</span> <span class="n">ex</span><span class="o">|</span>
<span class="n">notify</span><span class="o">[</span><span class="s1">'failed'</span><span class="p">,</span> <span class="n">title</span><span class="p">,</span> <span class="n">message</span><span class="o">]</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>You can place this code inside <code>buildr.rb</code> in the <code>.buildr</code> directory under your home directory.</p>
+</code></pre></div><p>You can place this code inside <code>buildr.rb</code> in the <code>.buildr</code> directory under your home directory.</p>
<h2 id="eclipse">Eclipse</h2>
<h3>Use Apache Buildr to create Eclipse projects</h3>
<p>If you’re using Eclipse, you can generate <code>.classpath</code> and <code>.project</code> from your Buildfile and use them to create a project in your workspace:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr eclipse
-</code></pre>
-</div>
-<p>The <code>eclipse</code> task will generate a <code>.classpath</code> and <code>.project</code> file for each of projects (and sub-project) that compiles source code. It will not generate files for other projects, for examples, projects you use strictly for packaging a distribution, or creating command line scripts, etc.</p>
+</code></pre></div><p>The <code>eclipse</code> task will generate a <code>.classpath</code> and <code>.project</code> file for each of projects (and sub-project) that compiles source code. It will not generate files for other projects, for examples, projects you use strictly for packaging a distribution, or creating command line scripts, etc.</p>
<p>If you add a new project, change the dependencies, or make any other change to your Buildfile, just run the <code>eclipse</code> task again to re-generate the Eclipse project files. To have your libraries’ source code available in Eclipse, run the <code>artifacts:sources</code> task.</p>
<p>You may explicitly specify the nature of your project, for example if you are developing an Eclipse plugin:</p>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s1">'my-plugin'</span> <span class="k">do</span>
<span class="n">eclipse</span><span class="o">.</span><span class="n">natures</span> <span class="ss">:plugin</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>The currently supported natures are <code>:java</code>, <code>:scala</code> and <code>:plugin</code>. Buildr will attempts to auto-detect your project type and apply the most relevant settings by default. If it doesn’t or you need something special, you may also explicitly set the nature, container and builders of your project by doing:</p>
+</code></pre></div><p>The currently supported natures are <code>:java</code>, <code>:scala</code> and <code>:plugin</code>. Buildr will attempts to auto-detect your project type and apply the most relevant settings by default. If it doesn’t or you need something special, you may also explicitly set the nature, container and builders of your project by doing:</p>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s1">'custom-plugin'</span> <span class="k">do</span>
<span class="n">eclipse</span><span class="o">.</span><span class="n">natures</span> <span class="s1">'org.eclipse.pde.PluginNature'</span>
<span class="n">eclipse</span><span class="o">.</span><span class="n">classpath_containers</span> <span class="s1">'org.eclipse.pde.core.requiredPlugins'</span>
<span class="n">eclipse</span><span class="o">.</span><span class="n">builders</span> <span class="o">[</span><span class="s1">'org.eclipse.pde.ManifestBuilder'</span><span class="p">,</span> <span class="s1">'org.eclipse.pde.SchemaBuilder'</span><span class="o">]</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>One more thing; these settings are inherited hierarchically so you may set them on a parent project if you want to share them across different projects.</p>
+</code></pre></div><p>One more thing; these settings are inherited hierarchically so you may set them on a parent project if you want to share them across different projects.</p>
<h3>Use Apache Buildr to create a buildfile from an Eclipse workspace</h3>
<p>If you’re using Eclipse, you can generate a <code>buildfile</code> from a directory which contains one (or more) Eclipse projects somewhere in its sub-directories.</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr --generate /path/to/my_project
-</code></pre>
-</div>
-<p>This creates a basic buildfile with a main project called ‘my_project’. The buildfile contains a skeleton for compiling the Eclipse projects. If you want to automate dependency tracking via OSGi have a look at the <a href="http://oss.intalio.com/buildr4osgi/">buildr4osgi</a> project. Support for building Eclipse <span class="caps">RCP</span> applications, running <span class="caps">PDE</span> tests and P2-sites is currently lacking in Buildr.</p>
+</code></pre></div><p>This creates a basic buildfile with a main project called ‘my_project’. The buildfile contains a skeleton for compiling the Eclipse projects. If you want to automate dependency tracking via OSGi have a look at the <a href="http://oss.intalio.com/buildr4osgi/">buildr4osgi</a> project. Support for building Eclipse <span class="caps">RCP</span> applications, running <span class="caps">PDE</span> tests and P2-sites is currently lacking in Buildr.</p>
<h2 id="idea">IntelliJ <span class="caps">IDEA</span></h2>
<p>If you use IntelliJ <span class="caps">IDEA</span>, you can generate project files by issuing:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr idea
-</code></pre>
-</div>
-<p>This task will generate a <code>.iml</code> file for every project (or subproject) and a <code>.ipr</code> that you can directly open for the root project.</p>
+</code></pre></div><p>This task will generate a <code>.iml</code> file for every project (or subproject) and a <code>.ipr</code> that you can directly open for the root project.</p>
<p>The generated project files can be removed by issuing:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr idea:clean
-</code></pre>
-</div>
-<p>The idea task generates the project files based on the settings of each project and idea extension specific settings. The main and test source trees are added to the <code>.iml</code> file for each project as are the respective resource directories. The target and report directories are excluded from the project. If the project files exist on the file system the extension will replace specific component sections in the xml with the generated component configurations.</p>
+</code></pre></div><p>The idea task generates the project files based on the settings of each project and idea extension specific settings. The main and test source trees are added to the <code>.iml</code> file for each project as are the respective resource directories. The target and report directories are excluded from the project. If the project files exist on the file system the extension will replace specific component sections in the xml with the generated component configurations.</p>
<p>Dependencies come in two forms. Dependencies on other projects and dependencies on external jars. Dependencies on other projects are added as module dependencies in the <code>.iml</code> while jars are added as regular file dependencies. Dependencies are exported from the <code>.iml</code> file if they are compile dependencies. If a artifact that matches dependency but has a classifier of ‘sources’ is present then it is configured as the source for the dependency. Note: Use “buildr artifacts:sources” to download the source for dependencies.</p>
<h3>Idea Specific Directives</h3>
<p>The extension specific settings of sub-projects inherit the parent projects settings unless overwritten.</p>
@@ -416,9 +358,7 @@ scala> </pre>
<span class="n">iml</span><span class="o">.</span><span class="n">id</span> <span class="o">=</span> <span class="s2">"baz"</span>
<span class="k">end</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>Will generate:</p>
+</code></pre></div><p>Will generate:</p>
<pre>
beep.ipr
foo.iml
@@ -430,9 +370,7 @@ bar/baz.iml
<span class="n">iml</span><span class="o">.</span><span class="n">suffix</span> <span class="o">=</span> <span class="s2">"-suffix2"</span>
<span class="n">define</span> <span class="s2">"bar"</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>Will generate:</p>
+</code></pre></div><p>Will generate:</p>
<pre>
foo-suffix1.ipr
foo-suffix2.iml
@@ -447,9 +385,7 @@ bar/bar-suffix2.iml
<span class="n">project</span><span class="o">.</span><span class="n">no_iml</span>
<span class="k">end</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>Will generate:</p>
+</code></pre></div><p>Will generate:</p>
<pre>
foo.iml
</pre>
@@ -459,17 +395,13 @@ foo.iml
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s2">"foo"</span> <span class="k">do</span>
<span class="n">iml</span><span class="o">.</span><span class="n">skip_content!</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<h4><span class="caps">VCS</span> Integration</h4>
+</code></pre></div><h4><span class="caps">VCS</span> Integration</h4>
<p>The extension will attempt to guess the <span class="caps">VCS</span> type of the project by looking for a <code>.svn</code> or <code>.git</code> directory in the base projects directory. If either of these are set it will configure the component as appropriate. Otherwise the user will need to manually specify the project to one of either ‘Git’ or ‘svn’ using the ipr.vcs setting.</p>
<h5>Example</h5>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s2">"foo"</span> <span class="k">do</span>
<span class="n">ipr</span><span class="o">.</span><span class="n">vcs</span> <span class="o">=</span> <span class="s1">'Git'</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<h4>Adding main, test or exclude paths to the .iml file</h4>
+</code></pre></div><h4>Adding main, test or exclude paths to the .iml file</h4>
<p>The extension allows you to add source paths, test source paths or add paths to the excluded set by modifying the “iml.main_source_directories”, “iml.test_source_directories” or “iml.excluded_directories” settings respectively. This is only needed when the defaults inherited from project.compile or project.test are not sufficient.</p>
<h5>Example</h5>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s2">"foo"</span> <span class="k">do</span>
@@ -484,9 +416,7 @@ foo.iml
<span class="o">.</span><span class="n">.</span><span class="o">.</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<h4>Adding main or test dependencies to the .iml file</h4>
+</code></pre></div><h4>Adding main or test dependencies to the .iml file</h4>
<p>The extension allows you to add main or test dependencies by modifying the “iml.main_dependencies” or “iml.test_dependencies” settings respectively. This is only needed when the defaults inherited from project.compile or project.test are not sufficient. Note: These dependencies are not included on compile path when running buildr.</p>
<h5>Example</h5>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s2">"foo"</span> <span class="k">do</span>
@@ -497,18 +427,14 @@ foo.iml
<span class="n">iml</span><span class="o">.</span><span class="n">test_dependencies</span> <span class="o"><<</span> <span class="s1">'group:id:jar:1.0'</span>
<span class="o">.</span><span class="n">.</span><span class="o">.</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<h4>Dependency generation</h4>
+</code></pre></div><h4>Dependency generation</h4>
<p>A file dependency that exists in the local maven 2 repository is stored in the <span class="caps">IML</span> file relative to the <code>$MAVEN_REPOSITORY$</code> environment variable (that defaults to <code>~/.m2/repository</code>). The user can override the environment variable by setting the “iml.local_repository_env_override” setting. If the dependency does not exist in to maven repository or the “iml.local_repository_env_override” setting is set to nil, then the path stored in the <span class="caps">IML</span> is relative to the <span class="caps">IML</span> file.</p>
<h5>Example: Setting local_repository_env_override</h5>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s2">"foo"</span> <span class="k">do</span>
<span class="n">iml</span><span class="o">.</span><span class="n">local_repository_env_override</span> <span class="o">=</span> <span class="kp">nil</span>
<span class="n">compile</span><span class="o">.</span><span class="n">with</span> <span class="s1">'group:id:jar:1.0'</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>Will generate a dependency with a path like:</p>
+</code></pre></div><p>Will generate a dependency with a path like:</p>
<pre>
jar:///home/peter/.m2/repository/group/id/1.0/id-1.0.jar!/
</pre>
@@ -520,9 +446,7 @@ jar://$MAVEN_REPOSITORY$/group/id/1.0/id
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s2">"foo"</span> <span class="k">do</span>
<span class="n">compile</span><span class="o">.</span><span class="n">with</span> <span class="n">_</span><span class="p">(</span><span class="s2">"foos-dep.jar"</span><span class="p">)</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>Will generate a dependency with a path like:</p>
+</code></pre></div><p>Will generate a dependency with a path like:</p>
<pre>
jar://$MODULE_DIR$/foo-dep.jar!/
</pre>
@@ -544,9 +468,7 @@ jar://$MODULE_DIR$/foo-dep.jar!/
<span class="k">end</span>
<span class="k">end</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<h4>Project Configurations</h4>
+</code></pre></div><h4>Project Configurations</h4>
<p>Configurations are IDEAs mechanism for running or debugging the project. Shared configurations are stored in the project file. The extension makes it possible to generate an <code>.ipr</code> with specific configurations via the “ipr.add_configuration” method.</p>
<h5>Example</h5>
<p>This example adds a configuration to invoke a <span class="caps">GWT</span> application.</p>
@@ -563,9 +485,7 @@ jar://$MODULE_DIR$/foo-dep.jar!/
<span class="n">xml</span><span class="o">.</span><span class="n">method</span><span class="p">()</span>
<span class="k">end</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<h4>Project Artifacts</h4>
+</code></pre></div><h4>Project Artifacts</h4>
<p><span class="caps">IDEA</span> can build artifacts such as jars and wars. The artifact configuration is stored in the project file. The extension makes it possible to generate an <code>.ipr</code> with specific artifacts via the “ipr.add_artifact” method.</p>
<h5>Example</h5>
<p>This example adds a jar artifact to the project.</p>
@@ -576,9 +496,7 @@ jar://$MODULE_DIR$/foo-dep.jar!/
<span class="n">xml</span><span class="o">.</span><span class="n">element</span> <span class="ss">:id</span> <span class="o">=></span> <span class="s2">"module-output"</span><span class="p">,</span> <span class="ss">:name</span> <span class="o">=></span> <span class="s2">"foo"</span>
<span class="k">end</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<h4>Custom Component Sections</h4>
+</code></pre></div><h4>Custom Component Sections</h4>
<p>If the extension does not provide capability to generate configuration for a particular <span class="caps">IDEA</span> plugin the user can provide their own configuration data via the “ipr.add_component” or “iml.add_component” methods.</p>
<h5>Example: Adding .ipr specific component</h5>
<p>This example changes the compiler configuration for project.</p>
@@ -594,9 +512,7 @@ jar://$MODULE_DIR$/foo-dep.jar!/
<span class="k">end</span>
<span class="k">end</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<h5>Example: Adding .iml specific component</h5>
+</code></pre></div><h5>Example: Adding .iml specific component</h5>
<p>This example adds the web facet to a project. Note: This overrides the facets defined by the “iml.add_facet” method.</p>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s2">"foo"</span> <span class="k">do</span>
<span class="n">iml</span><span class="o">.</span><span class="n">add_component</span><span class="p">(</span><span class="s2">"FacetManager"</span><span class="p">)</span> <span class="k">do</span> <span class="o">|</span><span class="n">component</span><span class="o">|</span>
@@ -614,18 +530,14 @@ jar://$MODULE_DIR$/foo-dep.jar!/
<span class="k">end</span>
<span class="k">end</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<h4>Templates</h4>
+</code></pre></div><h4>Templates</h4>
<p>The underlying project files are xml the contain elements for a number of “components”. The extension will load any existing project files and replace or add any component elements that are generated by the extension. The extension also allows the user to specify a template with either “ipr.template” or “iml.template” settings. If a template is specified it will be loaded and any component elements in these documents will be merged into the base document prior to merging in generated sections. Templates are useful if you want to enforce certain configuration options (i.e. project specific code style).</p>
<h5>Example</h5>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s2">"foo"</span> <span class="k">do</span>
<span class="n">ipr</span><span class="o">.</span><span class="n">template</span> <span class="o">=</span> <span class="s1">'project.ipr.template'</span>
<span class="n">iml</span><span class="o">.</span><span class="n">template</span> <span class="o">=</span> <span class="s1">'module.iml.template'</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<h4>Groups</h4>
+</code></pre></div><h4>Groups</h4>
<p><span class="caps">IDEA</span> provides the facility to organise modules into groups. By default the extension does not do this but it can be enabled by “iml.group” setting. If that setting is set to true then the <code>.iml</code> file will be placed in a group based on the parent projects name. If the setting is a string then that is used as the name of the group.</p>
<h5>Example</h5>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s2">"foo"</span> <span class="k">do</span>
@@ -637,9 +549,7 @@ jar://$MODULE_DIR$/foo-dep.jar!/
<span class="n">iml</span><span class="o">.</span><span class="n">group</span> <span class="o">=</span> <span class="s2">"MyGroup"</span>
<span class="k">end</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>Will place the generated .imls in the following groups:</p>
+</code></pre></div><p>Will place the generated .imls in the following groups:</p>
<pre>
foo.iml => ''
bar/bar.iml => 'foo'
@@ -653,32 +563,24 @@ rab/rab.iml => 'MyGroup'
<span class="n">ipr</span><span class="o">.</span><span class="n">extra_modules</span> <span class="o"><<</span> <span class="s1">'other.iml'</span>
<span class="n">ipr</span><span class="o">.</span><span class="n">extra_modules</span> <span class="o"><<</span> <span class="s1">'other_other.iml'</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>Will add the ‘other.iml’ and ‘other_other.iml’ files to the <code>.ipr</code> project files.</p>
+</code></pre></div><p>Will add the ‘other.iml’ and ‘other_other.iml’ files to the <code>.ipr</code> project files.</p>
<h4>Buildr plugin for <span class="caps">IDEA</span></h4>
<p>Also, check out the <a href="http://www.digitalsanctum.com/buildr-plug-in/">Buildr plugin for <span class="caps">IDEA</span></a> (<span class="caps">IDEA</span> 7 and later). Once installed, open your project with <span class="caps">IDEA</span>. If <span class="caps">IDEA</span> finds that you have Buildr installed and finds a buildfile in the project’s directory, it will show all the tasks available for that project. To run a task, double-click it. When the task completes, <span class="caps">IDEA</span> will show the results in the Buildr Output window.</p>
<h2 id="cobertura_emma">Cobertura, Emma</h2>
<p>You can use <a href="http://cobertura.sourceforge.net/">Cobertura</a> or <a href="http://emma.sourceforge.net/">Emma</a> to instrument your code, run the tests and create a test coverage report in either <span class="caps">HTML</span> or <span class="caps">XML</span> format.</p>
<p>There are two main tasks for each tool, both of which generate a test coverage report in the <code>reports/cobertura</code> (respectively <code>reports/emma</code>) directory. For example:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr <span class="nb">test </span>cobertura:html
-</code></pre>
-</div>
-<p>As you can guess, the other tasks are <code>cobertura:xml</code>, <code>emma:html</code> and <code>emma:xml</code>.</p>
+</code></pre></div><p>As you can guess, the other tasks are <code>cobertura:xml</code>, <code>emma:html</code> and <code>emma:xml</code>.</p>
<p>If you want to generate a test coverage report only for a specific project, you can do so by using the project name as prefix to the tasks.</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr subModule:cobertura:html
-</code></pre>
-</div>
-<p>Each project can specify which classes to include or exclude from cobertura instrumentation by giving a class-name regexp to the <code>cobertura.include</code> or <code>cobertura.exclude</code> methods:</p>
+</code></pre></div><p>Each project can specify which classes to include or exclude from cobertura instrumentation by giving a class-name regexp to the <code>cobertura.include</code> or <code>cobertura.exclude</code> methods:</p>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s1">'someModule'</span> <span class="k">do</span>
<span class="n">cobertura</span><span class="o">.</span><span class="n">include</span> <span class="s1">'some.package.==*=='</span>
- <span class="n">cobertura</span><span class="o">.</span><span class="n">include</span><span class="sr"> /some.(foo|bar).==*==/</span>
+ <span class="n">cobertura</span><span class="o">.</span><span class="n">include</span> <span class="sr">/some.(foo|bar).==*==/</span>
<span class="n">cobertura</span><span class="o">.</span><span class="n">exclude</span> <span class="s1">'some.foo.util.SimpleUtil'</span>
<span class="n">cobertura</span><span class="o">.</span><span class="n">exclude</span> <span class="o">/==*==.</span><span class="n">Const</span><span class="p">(</span><span class="n">ants</span><span class="p">)?</span><span class="o">/</span><span class="n">i</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>Emma has <code>include</code> and <code>exclude</code> methods too, but they take glob patterns instead of regexps.</p>
+</code></pre></div><p>Emma has <code>include</code> and <code>exclude</code> methods too, but they take glob patterns instead of regexps.</p>
<p>Cobertura also provides a <code>cobertura:check</code> task. This task is intended to be used as a dependency for other tasks (such as <code>deploy</code>) which might wish to fail if coverage is unacceptable. The respective thresholds for task failure may be defined using the <code>cobertura.check</code> configuration namespace. For example:</p>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s1">'someModule'</span> <span class="k">do</span>
<span class="n">cobertura</span><span class="o">.</span><span class="n">check</span><span class="o">.</span><span class="n">branch_rate</span> <span class="o">=</span> <span class="mi">75</span>
@@ -687,20 +589,14 @@ rab/rab.iml => 'MyGroup'
<span class="n">task</span><span class="p">(</span><span class="ss">:deploy</span><span class="p">)</span><span class="o">.</span><span class="n">enhance</span> <span class="s1">'cobertura:check'</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>The <code>cobertura:check</code> task supports all of the configuration parameters allowed by the <code>cobertura-check</code> Ant task (as <a href="http://cobertura.sourceforge.net/anttaskreference.html">documented here</a>). Configuration parameters are “Ruby-ized” (as demonstrated in the example above).</p>
+</code></pre></div><p>The <code>cobertura:check</code> task supports all of the configuration parameters allowed by the <code>cobertura-check</code> Ant task (as <a href="http://cobertura.sourceforge.net/anttaskreference.html">documented here</a>). Configuration parameters are “Ruby-ized” (as demonstrated in the example above).</p>
<p>We want Buildr to load fast, and not everyone cares for these tasks, so we don’t include them by default. If you want to use one of them, you need to require it explicitly. The proper way to do it in Ruby:</p>
<div class="highlight"><pre><code class="ruby"><span class="nb">require</span> <span class="s1">'buildr/java/cobertura'</span>
<span class="nb">require</span> <span class="s1">'buildr/java/emma'</span>
-</code></pre>
-</div>
-<p>You may want to add those to the Buildfile. Alternatively, you can use these tasks for all your projects without modifying the Buildfile. One convenient method is to add these lines to the <code>buildr.rb</code> file in the <code>.buildr</code> directory under your home directory.</p>
+</code></pre></div><p>You may want to add those to the Buildfile. Alternatively, you can use these tasks for all your projects without modifying the Buildfile. One convenient method is to add these lines to the <code>buildr.rb</code> file in the <code>.buildr</code> directory under your home directory.</p>
<p>Another option is to require it from the command line (<code>--require</code> or <code>-r</code>), for example:</p>
<div class="highlight"><pre><code class="sh"><span class="nv">$ </span>buildr -rbuildr/java/cobertura cobertura:html
-</code></pre>
-</div>
-<h2 id="checkstyle">Checkstyle</h2>
+</code></pre></div><h2 id="checkstyle">Checkstyle</h2>
<p>Checkstyle is integrated into Buildr through an extension. The extension adds the “checkstyle:xml” task that generates an xml report listing checkstyle violations and may add a “checkstyle:html” task if an appropriate xsl is present. A typical project that uses the extension may look something like;</p>
<div class="highlight"><pre><code class="ruby"><span class="nb">require</span> <span class="s1">'buildr/checkstyle'</span>
@@ -714,9 +610,7 @@ rab/rab.iml => 'MyGroup'
<span class="n">checkstyle</span><span class="o">.</span><span class="n">extra_dependencies</span> <span class="o"><<</span> <span class="ss">:javax_servlet</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>By default checkstyle will look for all configuration files in the src/main/etc/checkstyle directory but this can be overriden by the setting the “checkstyle.config_directory” parameter. The “checkstyle:xml” task will be defined if the checkstyle rules file is found. The rules file is typically named “checks.xml” but can be overridden by setting the “checkstyle.configuration_file” parameter. If a suppressions file or import control file is included in the directory, these will also be used by the extension. These names of these files will default to “suppressions.xml” and “import-control.xml” but these can be overriden by the parameters “checkstyle.suppressions_file” and “checkstyle.import_control_file”.</p>
+</code></pre></div><p>By default checkstyle will look for all configuration files in the src/main/etc/checkstyle directory but this can be overriden by the setting the “checkstyle.config_directory” parameter. The “checkstyle:xml” task will be defined if the checkstyle rules file is found. The rules file is typically named “checks.xml” but can be overridden by setting the “checkstyle.configuration_file” parameter. If a suppressions file or import control file is included in the directory, these will also be used by the extension. These names of these files will default to “suppressions.xml” and “import-control.xml” but these can be overriden by the parameters “checkstyle.suppressions_file” and “checkstyle.import_control_file”.</p>
<p>The extension will include the source and test directories of the project aswell as the compile and test dependencies when invoking the checkstyle tool. These can be added to by the parameters “checkstyle.source_paths” and “checkstyle.extra_dependencies” as appropriate.</p>
<p>If the xsl file named “checkstyle-report.xsl” is present in the configuration directory then a “checkstyle:html” task will be defined. The name of the xsl file can be overridden by the parameter “checkstyle.style_file”.</p>
<h2 id="findbugs">FindBugs</h2>
@@ -734,9 +628,7 @@ rab/rab.iml => 'MyGroup'
<span class="n">findbugs</span><span class="o">.</span><span class="n">extra_dependencies</span> <span class="o"><<</span> <span class="n">project</span><span class="p">(</span><span class="s1">'bar'</span><span class="p">)</span><span class="o">.</span><span class="n">compile</span><span class="o">.</span><span class="n">dependencies</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>By default findbugs will look for all configuration files in the src/main/etc/findbugs directory but this can be overriden by the setting the “findbugs.config_directory” parameter. The “findbugs:xml” task will past FindBugs a filter xml if a file named “filter.xml” is present in the configuration directory. This can be overridden by setting the “findbugs.filter_file” parameter.</p>
+</code></pre></div><p>By default findbugs will look for all configuration files in the src/main/etc/findbugs directory but this can be overriden by the setting the “findbugs.config_directory” parameter. The “findbugs:xml” task will past FindBugs a filter xml if a file named “filter.xml” is present in the configuration directory. This can be overridden by setting the “findbugs.filter_file” parameter.</p>
<p>The extension will include the source and test directories of the project aswell as the compile and test dependencies when invoking the findbugs tool. These can be added to by the parameters “findbugs.source_paths” and “findbugs.extra_dependencies” as appropriate. The actual analysis is run across compiled artifacts ad this will default to the target directory of the project but this can be overriden by the “findbugs.analyze_paths” parameter.</p>
<p>If the xsl file named “findbugs-report.xsl” is present in the configuration directory then a “findbugs:html” task will be defined. The name of the xsl file can be overridden by the parameter “findbugs.style_file”.</p>
<h2 id="javancss">JavaNCSS</h2>
@@ -753,9 +645,7 @@ rab/rab.iml => 'MyGroup'
<span class="n">javancss</span><span class="o">.</span><span class="n">source_paths</span> <span class="o"><<</span> <span class="n">project</span><span class="p">(</span><span class="s1">'bar'</span><span class="p">)</span><span class="o">.</span><span class="n">_</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">:java</span><span class="p">)</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>The extension will include the source and test directories of the project when invoking the javancss tool. These can be added to by the parameters “javancss.source_paths”.</p>
+</code></pre></div><p>The extension will include the source and test directories of the project when invoking the javancss tool. These can be added to by the parameters “javancss.source_paths”.</p>
<p>By default javancss will look for all configuration files in the src/main/etc/javancss directory but this can be overriden by the setting the “javancss.config_directory” parameter. The “javancss:xml” task will be defined if the “javancss.enabled” property is set to true. If the xsl file named “javancss2html.xsl” is present in the configuration directory then a “javancss:html” task will be defined. The name of the xsl file can be overridden by the parameter “javancss.style_file”.</p>
<h2 id="jdepend">JDepend</h2>
<p><a href="http://clarkware.com/software/JDepend.html">JDepend</a> is integrated into Buildr through an extension. The extension adds the “jdepend:xml” task that generates an xml report, “jdepend:swing” that shows a Swing UI, and may add a “jdepend:html” task if an appropriate xsl is present. A typical project that uses the extension may look something like;</p>
@@ -771,9 +661,7 @@ rab/rab.iml => 'MyGroup'
<span class="n">jdepend</span><span class="o">.</span><span class="n">target_paths</span> <span class="o"><<</span> <span class="n">project</span><span class="p">(</span><span class="s1">'bar'</span><span class="p">)</span><span class="o">.</span><span class="n">compile</span><span class="o">.</span><span class="n">target</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>The extension will include the compiled source and test directories of the project when invoking the JDepend tool. These can be added to by the parameters “jdepend.target_paths”.</p>
+</code></pre></div><p>The extension will include the compiled source and test directories of the project when invoking the JDepend tool. These can be added to by the parameters “jdepend.target_paths”.</p>
<p>By default JDepend will look for all configuration files in the src/main/etc/jdepend directory but this can be overriden by the setting the “jdepend.config_directory” parameter. The “jdepend:xml” and “jdepend:swing” task will be defined if the “jdepend.enabled” property is set to true. If a “jdepend.properties” is included in the configuration directory then jdepend will load it during the analysis. If the xsl file named “jdepend.xsl” is present in the configuration directory then a “jdepend:html” task will be defined. The name of the xsl file can be overridden by the parameter “jdepend.style_file”.</p>
<h2 id="pmd"><span class="caps">PMD</span></h2>
<p><span class="caps">PMD</span> is integrated into Buildr through an extension. The extension adds the “pmd:rule:xml” and “pmd:rule:html” tasks. A typical project that uses the extension may look something like;</p>
@@ -790,9 +678,7 @@ rab/rab.iml => 'MyGroup'
<span class="n">pmd</span><span class="o">.</span><span class="n">rule_set_files</span> <span class="o">=</span> <span class="o">[</span><span class="s1">'basic'</span><span class="p">,</span><span class="s1">'imports'</span><span class="p">,</span><span class="s1">'unusedcode'</span><span class="p">,</span><span class="s1">'logging-java'</span><span class="p">,</span><span class="s1">'finalizers'</span><span class="o">]</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>The “pmd:rule:xml” task will be defined if the “pmd.enabled” property is set to true.</p>
+</code></pre></div><p>The “pmd:rule:xml” task will be defined if the “pmd.enabled” property is set to true.</p>
<p>The extension will include the source and test directories of the project when invoking the pmd tool. These can be added to by the parameters “pmd.source_paths”.</p>
<p>By default the pmd rule files ‘basic’,‘imports’ and ‘unusedcode’ will be evaluated but this can be overriden by the “pmd.rule_set_files” parameter. The rule sets will be loaded from the classpath and this can be added to by modifying the “pmd.rule_set_paths” parameter.</p>
<h2 id="sonar">Sonar</h2>
@@ -817,9 +703,7 @@ rab/rab.iml => 'MyGroup'
<span class="n">sonar</span><span class="o">.</span><span class="n">libraries</span> <span class="o"><<</span> <span class="n">project</span><span class="p">(</span><span class="s1">'foo:bar'</span><span class="p">)</span><span class="o">.</span><span class="n">compile</span><span class="o">.</span><span class="n">dependencies</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>The “sonar” task will be defined if the “sonar.enabled” property is set to true.</p>
+</code></pre></div><p>The “sonar” task will be defined if the “sonar.enabled” property is set to true.</p>
<p>Defaults exist for the “project_name”, “key”, “sources”, “binaries” and “libraries” parameters but the others should be set explicitly. The extension will include the source and test directories of the project as sources by default, the target directory as a binary and the dependencies as libraries.</p>
<h2 id="jaxb_xjc"><span class="caps">JAXB</span> Xjc Compiler</h2>
<p>Buildr includes an extension that provides the ability to invoke jaxb xjc binding compiler. A typical project that uses the extension may look something like;</p>
@@ -832,9 +716,7 @@ rab/rab.iml => 'MyGroup'
<span class="ss">:package</span> <span class="o">=></span> <span class="s2">"org.foo.api"</span><span class="p">)</span>
<span class="n">package</span> <span class="ss">:jar</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>The method compile_jaxb accepts either an array of files or a single file as the first parameter. It then accepts 0 or more arguments that are passed to the underlying <span class="caps">XJC</span> compiler. The arguments are documented on the <a href="https://jaxb.dev.java.net/nonav/2.2.1/docs/xjc.html">jaxb site</a>. If the last argument is an options hash then the extension handles the options hash specially. The supported options include:</p>
+</code></pre></div><p>The method compile_jaxb accepts either an array of files or a single file as the first parameter. It then accepts 0 or more arguments that are passed to the underlying <span class="caps">XJC</span> compiler. The arguments are documented on the <a href="https://jaxb.dev.java.net/nonav/2.2.1/docs/xjc.html">jaxb site</a>. If the last argument is an options hash then the extension handles the options hash specially. The supported options include:</p>
<ul>
<li><tt>:directory</tt>: The directory to which source is generated. Defaults to <tt>_(:target, :generated, :jaxb)</tt></li>
<li><tt>:keep_content</tt>: By default the generated directory will be deleted. If <tt>true</tt> is specified for this parameter the directory will not be deleted.</li>
@@ -849,9 +731,7 @@ rab/rab.iml => 'MyGroup'
<span class="n">cp</span> <span class="n">task</span><span class="o">.</span><span class="n">prerequisites</span><span class="p">,</span> <span class="n">task</span><span class="o">.</span><span class="n">name</span>
<span class="n">chmod</span> <span class="mo">0755</span><span class="p">,</span> <span class="no">FileList</span><span class="o">[</span><span class="n">task</span><span class="o">.</span><span class="n">name</span> <span class="o">+</span> <span class="s1">'/==*==.sh'</span><span class="o">]</span><span class="p">,</span> <span class="ss">:verbose</span><span class="o">=></span><span class="kp">false</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>You can use functions to keep your code simple. For example, in the <span class="caps">ODE</span> project we create two binary distributions, both of which contain a common set of files, and one additional file unique to each distribution. We use a method to define the common distribution:</p>
+</code></pre></div><p>You can use functions to keep your code simple. For example, in the <span class="caps">ODE</span> project we create two binary distributions, both of which contain a common set of files, and one additional file unique to each distribution. We use a method to define the common distribution:</p>
<div class="highlight"><pre><code class="ruby"><span class="k">def</span> <span class="nf">distro</span><span class="p">(</span><span class="n">project</span><span class="p">,</span> <span class="nb">id</span><span class="p">)</span>
<span class="n">project</span><span class="o">.</span><span class="n">package</span><span class="p">(</span><span class="ss">:zip</span><span class="p">,</span> <span class="ss">:id</span><span class="o">=></span><span class="nb">id</span><span class="p">)</span><span class="o">.</span><span class="n">path</span><span class="p">(</span><span class="s2">"</span><span class="si">#{</span><span class="nb">id</span><span class="si">}</span><span class="s2">-</span><span class="si">#{</span><span class="n">version</span><span class="si">}</span><span class="s2">"</span><span class="p">)</span><span class="o">.</span><span class="n">tap</span> <span class="k">do</span> <span class="o">|</span><span class="n">zip</span><span class="o">|</span>
<span class="n">zip</span><span class="o">.</span><span class="n">include</span> <span class="n">meta_inf</span> <span class="o">+</span> <span class="o">[</span><span class="s1">'RELEASE_NOTES'</span><span class="p">,</span> <span class="s1">'README'</span><span class="o">].</span><span class="n">map</span> <span class="p">{</span> <span class="o">|</span><span class="n">f</span><span class="o">|</span> <span class="n">path_to</span><span class="p">(</span><span class="n">f</span><span class="p">)</span> <span class="p">}</span>
@@ -867,23 +747,18 @@ rab/rab.iml => 'MyGroup'
<span class="k">yield</span> <span class="n">zip</span>
<span class="k">end</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>And then use it in the project definition:</p>
+</code></pre></div><p>And then use it in the project definition:</p>
<div class="highlight"><pre><code class="ruby"><span class="n">define</span> <span class="s1">'distro-axis2'</span> <span class="k">do</span>
<span class="n">parent</span><span class="o">.</span><span class="n">distro</span><span class="p">(</span><span class="nb">self</span><span class="p">,</span> <span class="s2">"</span><span class="si">#{</span><span class="n">parent</span><span class="o">.</span><span class="n">id</span><span class="si">}</span><span class="s2">-war"</span><span class="p">)</span> <span class="p">{</span> <span class="o">|</span><span class="n">zip</span><span class="o">|</span>
<span class="n">zip</span><span class="o">.</span><span class="n">include</span> <span class="n">project</span><span class="p">(</span><span class="s1">'ode:axis2-war'</span><span class="p">)</span><span class="o">.</span><span class="n">package</span><span class="p">(</span><span class="ss">:war</span><span class="p">),</span> <span class="ss">:as</span><span class="o">=></span><span class="s1">'ode.war'</span> <span class="p">}</span>
<span class="k">end</span>
-</code></pre>
-</div>
-<p>Ruby’s functional style and blocks make some task extremely easy. For example, let’s say we wanted to count how many source files we have, and total number of lines:</p>
+</code></pre></div><p>Ruby’s functional style and blocks make some task extremely easy. For example, let’s say we wanted to count how many source files we have, and total number of lines:</p>
<div class="highlight"><pre><code class="ruby"><span class="n">sources</span> <span class="o">=</span> <span class="n">projects</span><span class="o">.</span><span class="n">map</span> <span class="p">{</span> <span class="o">|</span><span class="n">prj</span><span class="o">|</span> <span class="n">prj</span><span class="o">.</span><span class="n">compile</span><span class="o">.</span><span class="n">sources</span><span class="o">.</span>
<span class="n">map</span> <span class="p">{</span> <span class="o">|</span><span class="n">src</span><span class="o">|</span> <span class="no">FileList</span><span class="o">[</span><span class="s2">"</span><span class="si">#{</span><span class="n">src</span><span class="si">}</span><span class="s2">/**/*.java"</span><span class="o">]</span> <span class="p">}</span> <span class="p">}</span><span class="o">.</span><span class="n">flatten</span>
<span class="nb">puts</span> <span class="s2">"There are </span><span class="si">#{</span><span class="n">source</span><span class="o">.</span><span class="n">size</span><span class="si">}</span><span class="s2"> source files"</span>
<span class="n">lines</span> <span class="o">=</span> <span class="n">sources</span><span class="o">.</span><span class="n">inject</span><span class="p">(</span><span class="mi">0</span><span class="p">)</span> <span class="p">{</span> <span class="o">|</span><span class="n">lines</span><span class="p">,</span> <span class="n">src</span><span class="o">|</span> <span class="n">lines</span> <span class="o">+=</span> <span class="no">File</span><span class="o">.</span><span class="n">readlines</span><span class="p">(</span><span class="n">src</span><span class="p">)</span><span class="o">.</span><span class="n">size</span> <span class="p">}</span>
<span class="nb">puts</span> <span class="s2">"That contain </span><span class="si">#{</span><span class="n">lines</span><span class="si">}</span><span class="s2"> lines"</span>
-</code></pre>
-</div>
+</code></pre></div>
</div>
<div id='footer'>Copyright © 2007-2010 The Apache Software Foundation</div>
</div>