You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@buildr.apache.org by as...@apache.org on 2009/03/11 23:39:03 UTC
svn commit: r752665 [1/2] - in /buildr/trunk: doc/ doc/_layouts/ doc/css/
doc/pages/ rakelib/
Author: assaf
Date: Wed Mar 11 22:39:02 2009
New Revision: 752665
URL: http://svn.apache.org/viewvc?rev=752665&view=rev
Log:
Modified to build site using jekyll
Added:
buildr/trunk/doc/_layouts/
buildr/trunk/doc/_layouts/default.html
buildr/trunk/doc/artifacts.textile
- copied, changed from r752580, buildr/trunk/doc/pages/artifacts.textile
buildr/trunk/doc/building.textile
- copied, changed from r752580, buildr/trunk/doc/pages/building.textile
buildr/trunk/doc/contributing.textile
- copied, changed from r752580, buildr/trunk/doc/pages/contributing.textile
buildr/trunk/doc/download.textile
- copied, changed from r752580, buildr/trunk/doc/pages/download.textile
buildr/trunk/doc/extending.textile
- copied, changed from r752580, buildr/trunk/doc/pages/extending.textile
buildr/trunk/doc/getting_started.textile
- copied, changed from r752580, buildr/trunk/doc/pages/getting_started.textile
buildr/trunk/doc/index.textile
- copied, changed from r752580, buildr/trunk/doc/pages/index.textile
buildr/trunk/doc/languages.textile
- copied, changed from r752580, buildr/trunk/doc/pages/languages.textile
buildr/trunk/doc/mailing_lists.textile
- copied, changed from r752580, buildr/trunk/doc/pages/mailing_lists.textile
buildr/trunk/doc/more_stuff.textile
- copied, changed from r752580, buildr/trunk/doc/pages/more_stuff.textile
buildr/trunk/doc/packaging.textile
- copied, changed from r752580, buildr/trunk/doc/pages/packaging.textile
buildr/trunk/doc/projects.textile
- copied, changed from r752580, buildr/trunk/doc/pages/projects.textile
buildr/trunk/doc/recipes.textile
- copied, changed from r752580, buildr/trunk/doc/pages/recipes.textile
buildr/trunk/doc/settings_profiles.textile
- copied, changed from r752580, buildr/trunk/doc/pages/settings_profiles.textile
buildr/trunk/doc/testing.textile
- copied, changed from r752580, buildr/trunk/doc/pages/testing.textile
buildr/trunk/doc/troubleshooting.textile
- copied, changed from r752580, buildr/trunk/doc/pages/troubleshooting.textile
buildr/trunk/doc/whats_new.textile
- copied, changed from r752580, buildr/trunk/doc/pages/whats_new.textile
Removed:
buildr/trunk/doc/pages/artifacts.textile
buildr/trunk/doc/pages/building.textile
buildr/trunk/doc/pages/contributing.textile
buildr/trunk/doc/pages/download.textile
buildr/trunk/doc/pages/extending.textile
buildr/trunk/doc/pages/getting_started.textile
buildr/trunk/doc/pages/index.textile
buildr/trunk/doc/pages/languages.textile
buildr/trunk/doc/pages/mailing_lists.textile
buildr/trunk/doc/pages/more_stuff.textile
buildr/trunk/doc/pages/packaging.textile
buildr/trunk/doc/pages/projects.textile
buildr/trunk/doc/pages/recipes.textile
buildr/trunk/doc/pages/settings_profiles.textile
buildr/trunk/doc/pages/testing.textile
buildr/trunk/doc/pages/troubleshooting.textile
buildr/trunk/doc/pages/whats_new.textile
buildr/trunk/doc/site.haml
Modified:
buildr/trunk/doc/css/default.css
buildr/trunk/doc/css/syntax.css
buildr/trunk/rakelib/doc.rake
Added: buildr/trunk/doc/_layouts/default.html
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/_layouts/default.html?rev=752665&view=auto
==============================================================================
--- buildr/trunk/doc/_layouts/default.html (added)
+++ buildr/trunk/doc/_layouts/default.html Wed Mar 11 22:39:02 2009
@@ -0,0 +1,84 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
+<html>
+ <head>
+ <meta content='text/html;charset=UTF-8' http-equiv='Content-Type' />
+ <title>buildr — {{ page.title }}</title>
+ <style type='text/css'>
+ @import 'css/default.css';
+ @import 'css/syntax.css';
+ </style>
+ <style media='print' type='text/css'>
+ @import 'css/print.css';
+ #header { display: none }
+ </style>
+ <meta content='Official Buildr documentation from the people in the know' name='subject' />
+ <link href='images/favicon.png' rel='shortcut icon' />
+ </head>
+ <body>
+ <div id='wrap'>
+ <div id='header'>
+ <a href='http://buildr.apache.org/'>
+ <img alt='buildr' src='images/buildr.png' />
+ </a>
+ <div class='tagline'></div>
+ </div>
+ <div id='pages'>
+ <ol class='toc'>
+ <li>Start Here
+ <ol class="toc">
+ <li><a href='index.html'>Welcome</a></li>
+ <li><a href='download.html'>Download</a></li>
+ <li><a href='buildr.pdf'>User Guide (PDF)</a></li>
+ <li><a href='whats_new.html'>What’s New</a></li>
+ <li><a href='http://cwiki.apache.org/confluence/display/BUILDR/Index'>Community Wiki</a></li>
+ </ol>
+ </li>
+ <li>Using Buildr
+ <ol class="toc">
+ <li><a href='getting_started.html'>Getting Started</a></li>
+ <li><a href='projects.html'>Projects</a></li>
+ <li><a href='building.html'>Building</a></li>
+ <li><a href='artifacts.html'>Artifacts</a></li>
+ <li><a href='packaging.html'>Packaging</a></li>
+ <li><a href='testing.html'>Testing</a></li>
+ <li><a href='settings_profiles.html'>Settings/Profiles</a></li>
+ <li><a href='languages.html'>Languages</a></li>
+ <li><a href='more_stuff.html'>More Stuff</a></li>
+ <li><a href='extending.html'>Extending Buildr</a></li>
+ <li><a href='recipes.html'>Recipes</a></li>
+ </ol>
+ </li>
+ <li>Reference
+ <ol class="toc">
+ <li><a href='rdoc'>API</a></li>
+ <li><a href='http://docs.rubyrake.org'>Rake</a></li>
+ <li><a href='http://antwrap.rubyforge.org'>Antwrap</a></li>
+ <li><a href='troubleshooting.html'>Troubleshooting</a></li>
+ </ol>
+ </li>
+ <li>Get Involved
+ <ol class="toc">
+ <li><a href='mailing_lists.html'>Mailing Lists</a></li>
+ <li><a href='http://issues.apache.org/jira/browse/Buildr'>Issues/Bugs</a></li>
+ <li><a href='contributing.html'>Contributing</a></li>
+ <li><a href='specs.html'>Specs</a></li>
+ <li><a href='coverage/index.html'>Coverage</a></li>
+ </ol>
+ </li>
+ </ol>
+ <form action='http://www.google.com/cse' id='searchbox_003673095760649043902:ogcgrzu0l2y'>
+ <input name='cx' type='hidden' value='003673095760649043902:ogcgrzu0l2y' />
+ <input name='cof' type='hidden' value='FORID:0' />
+ <input name='q' size='20' type='text' />
+ <input name='sa' type='submit' value='Search' />
+ <img alt='Google Custom Search' src='http://www.google.com/coop/images/google_custom_search_smnar.gif' />
+ </form>
+ </div>
+ <div id='content'>
+ <h1>{{ page.title }}</h1>
+ {{ content }}
+ </div>
+ <div id='footer'>Copyright © 2007-2009 The Apache Software Foundation</div>
+ </div>
+ </body>
+</html>
Copied: buildr/trunk/doc/artifacts.textile (from r752580, buildr/trunk/doc/pages/artifacts.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/artifacts.textile?p2=buildr/trunk/doc/artifacts.textile&p1=buildr/trunk/doc/pages/artifacts.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/artifacts.textile (original)
+++ buildr/trunk/doc/artifacts.textile Wed Mar 11 22:39:02 2009
@@ -1,4 +1,8 @@
-h1. Artifacts
+---
+layout: default
+title: Artifacts
+---
+
In Buildr, almost everything is a file or a file task. You compile source files that come from the file system using dependencies found on the file system, generating even more files. But how do you get these dependencies to start with, and how do you share them with others?
@@ -6,58 +10,59 @@
We'll get into all of that in a second, but first, let's introduce the artifact specification. It's a simple string that takes one of two forms:
-{{{
+{% highlight text %}
group:id:type:version
group:id:type:classifier:version
-}}}
+{% endhighlight %}
For example, @'org.apache.axis2:axis2:jar:1.2'@ refers to an artifact with group identifier org.apache.axis2, artifact identifier axis2, a JAR file with version 1.2. Classifiers are typically used to distinguish between similar file types, for example, a source distribution and a binary distribution that otherwise have the same identifier and are both ZIP files.
-h2. Specifying Artifacts
+h2(#specifying). Specifying Artifacts
If your Buildfile spells out @'org.apache.axis2:axis2:jar:1.2'@ more than once, you're doing something wrong. Repeating the same string over and over will make your code harder to maintain. You'll know that when you upgrade to a new version in one place, forget to do it in another, and end up with a mismatch.
You can use Ruby's syntax to do simple string substitution, for example:
-{{{!ruby
+{% highlight ruby %}
AXIS_VERSION = '1.2'
compile.with "org.apache.axis2:axis2:jar:#{AXIS_VERSION}"
-}}}
+{% endhighlight %}
Better yet, you can define all your artifacts at the top of the Buildfile and use constants to reference them in your project definition. For example:
-{{{!ruby
+{% highlight ruby %}
AXIS2 = 'org.apache.axis2:axis2:jar:1.2'
compile.with AXIS2
-}}}
+{% endhighlight %}
Note that we're not using a separate constant for the version number. In our experience, it's unnecessary. The version number intentionally appears at the end of the string, where it stands out easily.
If you have a set of artifacts that belong to the same group and version, and that's quite common, you can use the @group@ shortcut:
-{{{!ruby
+{% highlight ruby %}
AXIOM = group('axiom-api', 'axiom-impl', 'axiom-dom',
:under=>'org.apache.ws.commons.axiom', :version=>'1.2.4')
-}}}
+{% endhighlight %}
+<!-- -->
p(note). Buildr projects also define a @group@ attribute which can lead to some confusion. If you want to define an artifact group within a project definition, you should use the explicit qualifier @Buildr::group@.
If you have several artifacts you always use together, consider placing them in an array. Methods that accept lists of artifacts also accept arrays. For example:
-{{{!ruby
+{% highlight ruby %}
OPENJPA = ['org.apache.openjpa:openjpa-all:jar:0.9.7',
'net.sourceforge.serp:serp:jar:1.12.0']
AXIS_OF_WS = [AXIS2, AXIOM]
compile.with OPENJPA, AXIS_OF_WS
-}}}
+{% endhighlight %}
Another way to group related artifacts together and access them individually is using the @struct@ shortcut. For example:
-{{{!ruby
+{% highlight ruby %}
JAVAX = struct(
:activation =>'javax.activation:activation:jar:1.1',
:persistence =>'javax.persistence:persistence-api:jar:1.0',
@@ -65,79 +70,81 @@
)
compile.with JAVAX.persistence, OPENJPA
-}}}
+{% endhighlight %}
In our experience, using constants in this manner makes your Buildfile much easier to write and maintain.
And, of course, you can always place your artifact specifications in a separate file and require it into your Buildfile. For example, if you're working on several different projects that all share the same artifacts:
-{{{!ruby
+{% highlight ruby %}
require '../shared/artifacts'
-}}}
+{% endhighlight %}
When you use @require@, Ruby always looks for a filename with the @.rb@ extension, so in this case it expects to find @artifacts.rb@ in the @shared@ directory.
One last thing. You can also treat artifact specifications as hashes. For example:
-{{{!ruby
+{% highlight ruby %}
AXIS = { :group=>'org.apache.axis2', :id=>'axis2', :version=>'1.2' }
compile.with AXIS
puts compile.dependencies.first.to_hash
=> { :group=>'org.apache.axis2', :id=>'axis2',
:version=>'1.2', :type=>:jar }
-}}}
+{% endhighlight %}
+<!-- -->
-h2. Specifying Repositories
+h2(#repositories). Specifying Repositories
Buildr can download artifacts for you, but only if you tell it where to find them. You need to specify at least one remote repository, from which to download these artifacts.
When you call @repositories.remote@, you get an array of URLs for the various remote repositories. Initially, it's an empty array, to which you can add new repositories. For example:
-{{{!ruby
+{% highlight ruby %}
repositories.remote << 'http://www.ibiblio.org/maven2/'
-}}}
+{% endhighlight %}
If you need to use a proxy server to access remote repositories, you can set the environment variable @HTTP_PROXY@ to the proxy server URL. You can also work without a proxy for certain hosts by specifying the @NO_PROXY@ environment variable. For example:
-{{{!sh
+{% highlight sh %}
$ export HTTP_PROXY = 'http://myproxy:8080'
$ export NO_PROXY = '*.mycompany.com,localhost,special:800'
-}}}
+{% endhighlight %}
Alternatively you can use the Buildr options @proxy.http@ and @proxy.exclude@:
-{{{!ruby
+{% highlight ruby %}
options.proxy.http = 'http://myproxy:8080'
options.proxy.exclude << '*.mycompany.com'
options.proxy.exclude << 'localhost'
-}}}
+{% endhighlight %}
All the artifacts download into the local repository. Since all your projects share the same local repository, you only need to download each artifact once. Buildr was designed to be used alongside Maven 2.0, for example, when migrating projects from Maven 2.0 over to Buildr. By default it will share the same local repository, expecting the repository to be the @.m2/repository@ directory inside your home directory.
You can choose to relocate the local repository by giving it a different path, for example:
-{{{!ruby
+{% highlight ruby %}
repositories.local = '/usr/local/maven/repository'
-}}}
+{% endhighlight %}
That's one change you don't want to commit into the Buildfile, so the best place to do it is in your home directory's @buildr.rb@ file.
Buildr downloads artifacts when it needs to use them, for example, to compile a project. You don't need to download artifacts directly. Except when you do, for example, if you want to download all the latest artifacts and then go off-line. It's as simple as:
-{{{!sh
+{% highlight sh %}
$ buildr artifacts
-}}}
+{% endhighlight %}
+<!-- -->
-h2. Downloading Artifacts
+h2(#downloading). Downloading Artifacts
Within your buildfile you can download artifacts directly by invoking them, for example:
-{{{!ruby
+{% highlight ruby %}
artifact('org.apache.openjpa:openjpa-all:jar:0.9.7').invoke
artifacts(OPENJPA).each(&:invoke)
-}}}
+{% endhighlight %}
When you let Buildr download artifacts for you, or by invoking the artifact task yourself, it scans through the remote repositories assuming each repository follows the Maven 2 structure. Starting from the root repository URL, it will look for each artifact using the path @group/id/version/id-version.type@ (or ...@/id-version-classifier.type@). The group identifier becomes a path by turning periods (@.@) into slashes (@/@). So to find @org.apache.axis2:axis2:jar:1.2@, we're going to look for @org/apache/axis2/axis2/1.2/axis2-1.2.jar@.
@@ -147,12 +154,12 @@
We can still treat Dojo as an artifact, by telling Buildr where to download it from:
-{{{!ruby
+{% highlight ruby %}
DOJO = '0.2.2'
url = "http://download.dojotoolkit.org/release-#{DOJO}/dojo-#{DOJO}-widget.zip"
download(artifact("dojo:dojo:zip:widget:#{DOJO}")=>url)
-}}}
+{% endhighlight %}
Explaining how it works is tricky, skip if you don't care for the details. On the other hand, it will give you a better understanding of Buildr/Rake, so if not now, come back and read it later.
@@ -169,7 +176,7 @@
Magic.
-h2. Install and Upload
+h2(#install_upload). Install and Upload
Generally you use artifacts that download from remote repositories into the local repository, or artifacts packaged by the project itself (see "Packaging":packaging.html), which are then installed into the local repository and uploaded to the release server.
@@ -177,18 +184,18 @@
So let's start by creating a task that downloads the ZIP, and another one to extract it and create the JAR file:
-{{{!ruby
+{% highlight ruby %}
app_zip = download('target/app.zip'=>url)
bean_jar = file('target/app/bean.jar'=>unzip('target/app'=>app_zip))
-}}}
+{% endhighlight %}
When you call @artifact@, it returns an @Artifact@ task that points to the artifact file in the local repository, downloading the file if it doesn't already exist. You can override this behavior by enhancing the task and creating the file yourself (you may also want to create a POM file). Or much simpler, call the @from@ method on the artifact and tell it where to find the source file.
So the next step is to specify the artifact and tell it to use the extracted JAR file:
-{{{!ruby
+{% highlight ruby %}
bean = artifact('example.com:beans:jar:1.0').from(bean_jar)
-}}}
+{% endhighlight %}
The artifact still points to the local repository, but when we invoke the task it copies the source file over to the local repository, instead of attempting a download.
@@ -196,10 +203,11 @@
Our example ends by including the artifact in the @install@ and @upload@ tasks:
-{{{!ruby
+{% highlight ruby %}
install bean
upload bean
-}}}
+{% endhighlight %}
+<!-- -->
p(tip). Calling the @install@ (and likewise @upload@) method on an artifact run @buildr install@. If you need to download and install an artifact, invoke the task directly with @install(<artifact>).invoke@.
Copied: buildr/trunk/doc/building.textile (from r752580, buildr/trunk/doc/pages/building.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/building.textile?p2=buildr/trunk/doc/building.textile&p1=buildr/trunk/doc/pages/building.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/building.textile (original)
+++ buildr/trunk/doc/building.textile Wed Mar 11 22:39:02 2009
@@ -1,4 +1,8 @@
-h1. Building
+---
+layout: default
+title: Building
+---
+
To remove any confusion, Buildr's build task is actually called @build@. It's also the default task that executes when you run @buildr@ without any task name.
@@ -7,7 +11,7 @@
Why @build@ and not @compile@? Some projects do more than just compiling. Other projects don't compile at all, but perform other build tasks, for example, creating a database schema or command line scripts. So we want you to get in the practice of running the @build@ task, and help you by making it the default task.
-h2. Compiling
+h2(#compiling). Compiling
Each project has its own @compile@ task you can invoke directly, by running @buildr compile@ or as part of another build task. (Yes, that @build@).
@@ -27,10 +31,10 @@
For now let's just show a simple example:
-{{{!ruby
+{% highlight ruby %}
compile.with 'org.apache.axis2:axis2:jar:1.2',
'org.apache.derby:derby:jar:10.1.2.1', projects('teh-api', 'teh-impl')
-}}}
+{% endhighlight %}
Passing arrays to @compile.with@ is just a convenient for handling multiple dependencies, we'll show more examples of that when we talk about "Artifacts":#artifacts.
@@ -38,18 +42,18 @@
For example, let's run the APT tool on our annotated source code before compiling it:
-{{{!ruby
+{% highlight ruby %}
compile.from apt
-}}}
+{% endhighlight %}
When you call @apt@ on a project, it returns a file task that points to the @target/generated/apt@ directory. This file task executes by running APT, using the same list of source directories, dependencies and compiler options. It then generates new source files in the target directory. Calling @compile.from@ with that file task includes those additional source files in the list of compiled sources.
Here's another example:
-{{{!ruby
+{% highlight ruby %}
jjtree = jjtree(_('src/main/jjtree'), :in_package=>'com.acme')
compile.from javacc(jjtree, :in_package=>'com.acme'), jjtree
-}}}
+{% endhighlight %}
This time, the variable @jjtree@ is a file task that reads a JJTree source file from the @src/main/jjtree@ directory, and generates additional source files in the @target/generated/jjtree@ directory. The second line creates another file task that takes those source files, runs JavaCC on them, and generates yet more source files in @target/generated/javacc@. Finally, we include both sets of source files in addition to those already in @src/main/java@, and compile the lot.
@@ -61,10 +65,10 @@
For example:
-{{{!ruby
+{% highlight ruby %}
compile.from('srcs').with('org.apache.axis2:axis2:jar:1.2').
into('classes').using(:target=>'1.4')
-}}}
+{% endhighlight %}
Buildr uses the method pair and method chaining idiom in many places to make your life easier without sacrificing flexibility.
@@ -72,22 +76,22 @@
For example, to run the OpenJPA bytecode enhancer after compiling the source files:
-{{{!ruby
+{% highlight ruby %}
compile { open_jpa_enhance }
-}}}
+{% endhighlight %}
You can change various compile options by calling, you guessed, @compile.options@. For example, to set the compiler to VM compatibility with Java 1.5 and turn on all Lint messages:
-{{{!ruby
+{% highlight ruby %}
compile.options.target = '1.5'
compile.options.lint = 'all'
-}}}
+{% endhighlight %}
Or, if you want to chain methods together:
-{{{!ruby
+{% highlight ruby %}
compile.using :target=>'1.5', :lint=>'all'
-}}}
+{% endhighlight %}
Sub-projects inherit compile options from their parent project, so you only need to change these settings once in the top project. You can do so, even if the top project itself doesn't compile anything.
@@ -96,14 +100,14 @@
Buildr turns the @warning@ option on by default, but turns it off when you run @buildr --silent@. It also sets the @debug@ option on, but turns it off when making a release. You can also control the @debug@ option from the command line, for example:
-{{{!ruby
+{% highlight ruby %}
# When calling buildr
$ buildr compile debug=off
# Once until we change the variable
$ export DEBUG=off
$ buildr compile
-}}}
+{% endhighlight %}
The default source and target directories, compiler settings and other options you can use depend on the specific language. You can find more information in the "Languages":languages.html section.
@@ -115,14 +119,14 @@
The @resources@ task uses a filter that can change files as it copies them from source to destination. The most common use is by mapping values using a hash. For example, to substitute "${version}" for the project's version number and "${copyright}" for "Acme Inc (C) 2007" :
-{{{!ruby
+{% highlight ruby %}
resources.filter.using 'version'=>version,
'copyright'=>'Acme Inc (C) 2007'
-}}}
+{% endhighlight %}
You can also use "profiles":settings_profiles.html#profiles to supply a name/value map that all @resources@ task should default to, by adding a @filter@ element to each of the profiles. The following examples shows a @profiles.yaml@ file that applies the same filter in development and test environments:
-{{{!yaml
+{% highlight yaml %}
filter: &alpha1
version: experimental
copyright: Acme Inc (C) 2007
@@ -131,42 +135,42 @@
filter: *alpha1
test:
filter: *alpha1
-}}}
+{% endhighlight %}
You can specify a different format by passing it as the first argument. Supported formats include:
|_. Format |_. Usage |
-| @:ant@ | Map from <code>@key@</code> to value. |
+| @:ant@ | Map from @key@ to value. |
| @:maven@ | Map from @${key}@ to value (default). |
| @:ruby@ | Map from @#{key}@ to value. |
| @Regexp@ | Map using the matched value of the regular expression (e.g. @/=(.*?)=/@). |
For example, using the @:ruby@ format instead of the default @:maven@ format:
-{{{!ruby
+{% highlight ruby %}
resources.filter.using :ruby, 'version'=>version,
'copyright'=>'Acme Inc (C) 2007'
-}}}
+{% endhighlight %}
For more complicated mapping you can also pass a method or a proc. The filter will call it once for each file with the file name and content.
If you need to copy resource files from other directories, add these source directories by calling the @from@ method, for example:
-{{{!ruby
+{% highlight ruby %}
resources.from _('src/etc')
-}}}
+{% endhighlight %}
You can select to copy only specific files using common file matching patterns. For example, to include only HTML files:
-{{{!ruby
+{% highlight ruby %}
resources.include '*.html'
-}}}
+{% endhighlight %}
To include all files, except for files in the @scratch@ directory:
-{{{!ruby
+{% highlight ruby %}
resources.exclude 'scratch/*'
-}}}
+{% endhighlight %}
The filter always excludes the @CVS@ and @.svn@ directories, and all files ending with @.bak@ or @~@, so no need to worry about these.
@@ -176,10 +180,10 @@
For example:
-{{{!ruby
+{% highlight ruby %}
filter('src/specs').into('target/specs').
using('version'=>version, 'created'=>Time.now).run
-}}}
+{% endhighlight %}
The @resources@ task is, in fact, just a wrapper around such a filter that automatically adds the @src/main/resources@ directory as one of the source directories.
@@ -192,20 +196,20 @@
Let's look at a simple example. Say we want to generate a Derby database from an SQL file and include it in the ZIP package:
-{{{!ruby
+{% highlight ruby %}
db = Derby.create(_('target/derby/db')=>_('src/main/sql/derby.sql'))
package(:zip).include db
-}}}
+{% endhighlight %}
There's nothing fundamentally wrong with this code, if that's what you intend to do. But in practice, you don't always run the @package@ task during development, so you won't notice if something is wrong with this task when you build. For example, if it fails to generate the SQL file. In addition, the @package@ task runs after @build@, so you can't use the database in your test cases.
So let's refactor it. We're going to use the variable @db@ to reference the file task that creates the database, and make it a prerequisite of the @build@ task. And use that same variable again to include the database in the ZIP package:
-{{{!ruby
+{% highlight ruby %}
db = Derby.create(_('target/derby/db')=>_('src/main/sql/derby.sql'))
build db
package(:zip).include db
-}}}
+{% endhighlight %}
Much better. We're using the same task twice, but since we're using Rake here, it will only execute once. In fact, it will only execute if we don't already have a Derby database, or if it detects a change to the SQL file and needs to recreate the database.
@@ -213,12 +217,12 @@
Here's another example. We want to copy some files over as part of the build, and apply a filter to them. This time, we're going to extend the @build@ task:
-{{{!ruby
+{% highlight ruby %}
build do
filter('src/specs').into('target/specs').
using('version'=>version, 'created'=>Time.now).run
end
-}}}
+{% endhighlight %}
The @build@ task is recursive, so running @buildr build@ picks the current project and runs its @build@ task, which in turn runs the @build@ task on each of its sub-projects. One @build@ task to rule them all.
@@ -231,9 +235,9 @@
For example:
-{{{!ruby
+{% highlight ruby %}
clean { rm_rf _('staged') }
-}}}
+{% endhighlight %}
The @rm_rf@ method deletes the directory and all files in it. It's named after UNIX's infamous @rm -rf@. Use it wisely. This is also a good time to introduce you to @FileUtils@, a standard Ruby library that contains convenient methods for creating and deleting directories, copying and moving files, even comparing two files. They're all free of charge when you use Buildr.
Copied: buildr/trunk/doc/contributing.textile (from r752580, buildr/trunk/doc/pages/contributing.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/contributing.textile?p2=buildr/trunk/doc/contributing.textile&p1=buildr/trunk/doc/pages/contributing.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/contributing.textile (original)
+++ buildr/trunk/doc/contributing.textile Wed Mar 11 22:39:02 2009
@@ -1,20 +1,23 @@
-h1. Contributing
+---
+layout: default
+title: Contributing
+---
Buildr is a community effort, and we welcome all contributors. Here's your chance to get involved and help your fellow developers.
-h2. Getting involved
+h2(#involved). Getting involved
All our discussions are done in the open, over "email":mailing_lists.html, and that would be the first place to look for answers, raise ideas, etc. For bug reports, issues and patches, "see below":#bugs_aka_issues.
-h3. Mailing Lists
+h3(#mailing_lists). Mailing Lists
We run two mailing lists, the "users":http://mail-archives.apache.org/mod_mbox/buildr-users/ mailing list for developers working with Buildr, that would be you if you're using Buildr or interested in using it. There's the "dev":http://mail-archives.apache.org/mod_mbox/buildr-dev/ mailing list for talking about development of Buildr itself, and "commits":http://mail-archives.apache.org/mod_mbox/buildr-commits/ mailing list for following SVN commits and JIRA issues.
Check the "mailing lists":mailing_lists.html page for more information on subscribing, searching and posting to the mailing list.
-h3. Bugs (aka Issues)
+h3(#bugs). Bugs (aka Issues)
We really do try to keep bugs to a minimum, and anticipate everything you'll ever want to do with Buildr. We're also, not perfect. So you may have found a bug, or have an enhancement in mind, or better yet, a patch to contribute. Here's what you can do.
@@ -24,19 +27,21 @@
When reporting a bug, please tell us which version of Ruby, Buildr and Java you are using, and also which operating system you are on:
-{{{!sh
+<notextile>
+{% highlight sh %}
$ ruby --version
$ buildr --version
$ java --version
-}}}
+{% endhighlight %}
+</notextile>
-h3. Community Wiki
+h3(#wiki). Community Wiki
Our community Wiki is available at "http://cwiki.apache.org/confluence/display/BUILDR/Index":http://cwiki.apache.org/confluence/display/BUILDR/Index.
-h3. Contributing Code
+h3(#code). Contributing Code
Yes, please.
@@ -60,7 +65,7 @@
That way you can get other people involved, checking out the code, and eventually merge it back with the main branch. Check out the "Git section":#Git below and the post "Git forking for fun and profit":http://blog.labnotes.org/2008/04/30/git-forking-for-fun-and-profit/.
-h2. Living on the edge
+h2(#edge). Living on the edge
Did we mention Buildr is an open source project? In fact, when you install Buildr you get all the source code, documentation, test case and everything you need to use it, extend it and patch it. Have a look in your Gem directory.
@@ -68,19 +73,19 @@
But if you want to work with the latest and greatest, you'll want to check out "Buildr from SVN":http://svn.apache.org/repos/asf/buildr:
-{{{!sh
+{% highlight sh %}
$ svn co http://svn.apache.org/repos/asf/buildr/trunk buildr
-}}}
+{% endhighlight %}
You can also browse the "Buildr repository":http://svn.apache.org/repos/asf/buildr.
h3. Git
-Not a fan SVN? We understand. You can also grab a copy of "Buildr from GitHub":http://github.com/buildr/buildr/tree/master:
+Not a fan SVN? We understand. You can also grab a copy of "Buildr from GitHub":http://github.com/vic/buildr/tree/master:
-{{{!sh
-$ git clone git://github.com/buildr/buildr.git
-}}}
+{% highlight sh %}
+$ git clone git://github.com/vic/buildr.git
+{% endhighlight %}
If you want to learn more about Git, you can start by watching Scott Chaconâs "Git presentation":http://en.oreilly.com/rails2008/public/asset/attachment/2816 (PDF), or any of the "Git screencasts":http://www.gitcasts.com/. For more, there's also the "Git Internals book":http://peepcode.com/products/git-internals-pdf.
@@ -92,17 +97,17 @@
To install Buildr from the source directory:
-{{{!sh
+{% highlight sh %}
$ cd buildr
$ rake setup install
-}}}
+{% endhighlight %}
When using Buildr for JRuby:
-{{{!sh
+{% highlight sh %}
$ cd buildr
$ jruby -S rake setup install
-}}}
+{% endhighlight %}
The _setup_ task takes care of installing all the necessary dependencies used for building, testing and running Buildr. Once in a while we upgrade or add new dependencies, if you're experiencing a missing dependency, simply run @rake setup@ again.
@@ -115,21 +120,24 @@
Occasionally we'll make development builds from the current code in trunk/head. We appreciate if you can take the time to test those out and report any bugs. To install development builds, use the Gem repository at @people.apache.org/~assaf/buildr/snapshot@:
-{{{!sh
+{% highlight sh %}
gem source --add http://people.apache.org/~assaf/buildr/snapshot/
-}}}
+{% endhighlight %}
Since Ruby Gems uses version numbers to detect new releases, if you installed Buildr from a snapshot and want to upgrade to a newer snapshot or the latest official release, you need to use @gem install buildr@ rather than @gem upgrade@.
If you want to go back to using the RubyForge releases:
-{{{!sh
+<notextile>
+{% highlight sh %}
gem source --remove http://people.apache.org/~assaf/buildr/snapshot/
gem install buildr
-}}}
+{% endhighlight %}
+</notextile><!-- -->
-h2. Tested and Documented
+
+h2(#testing). Tested and Documented
Two things we definitely encourage!
@@ -141,18 +149,18 @@
You can run an individual specifications using the @spec@ command, for example:
-{{{!sh
+{% highlight sh %}
$ spec spec/compiler_spec.rb
$ spec spec/compiler_spec.rb -l 409
-}}}
+{% endhighlight %}
The first command will run all the specifications in @compiler_spec@, the second command will run only the specification identified by line 409 of that file. You can use line numbers to point at a particular specification (lines starting with @it@), or set of specifications (lines starting with @describe@). You can also use the @-e@ command line option to name a particular specification.
To make sure your change did not break anything else, you can run all the specifications (be patient, we have a lot of these):
-{{{!sh
+{% highlight sh %}
$ rake spec
-}}}
+{% endhighlight %}
If you get any failures, you can use @rake failed@ to run only the failed specs, and repeat until there are no more failed specs to run. The list of failed specs is stored in the file _failed_.
@@ -160,9 +168,9 @@
For full test coverage:
-{{{!sh
+{% highlight sh %}
$ rake coverage
-}}}
+{% endhighlight %}
Specification and coverage reports are HTML files you can view with a Web browser, look for them in the _reports_ directory. You can also check out the "RSpec report":specs.html and "test coverage":coverage/index.html we publish with each release.
@@ -187,7 +195,7 @@
first before you can @rake pdf@.
-h2. Contributors
+h2(#contributors). Contributors
Here is the list of people who are actively working and committing on Buildr:
Modified: buildr/trunk/doc/css/default.css
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/css/default.css?rev=752665&r1=752664&r2=752665&view=diff
==============================================================================
--- buildr/trunk/doc/css/default.css (original)
+++ buildr/trunk/doc/css/default.css Wed Mar 11 22:39:02 2009
@@ -44,10 +44,11 @@
pre {
margin: 0.3em 0 0.3em 0.9em;
padding: 0;
- line-height: 135%;
+ line-height: 1.8em;
white-space: pre-wrap; /* css-3 */
white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
}
+pre br { display: none; }
h1, h2, h3 {
padding: 0;
Modified: buildr/trunk/doc/css/syntax.css
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/css/syntax.css?rev=752665&r1=752664&r2=752665&view=diff
==============================================================================
--- buildr/trunk/doc/css/syntax.css (original)
+++ buildr/trunk/doc/css/syntax.css Wed Mar 11 22:39:02 2009
@@ -14,6 +14,9 @@
* under the License.
*/
+.nv { }
+.nb { }
+.o {}
.ruby .normal {}
.ruby .comment { color: gray; }
Copied: buildr/trunk/doc/download.textile (from r752580, buildr/trunk/doc/pages/download.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/download.textile?p2=buildr/trunk/doc/download.textile&p1=buildr/trunk/doc/pages/download.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/download.textile (original)
+++ buildr/trunk/doc/download.textile Wed Mar 11 22:39:02 2009
@@ -1,7 +1,10 @@
-h1. Download
+---
+layout: default
+title: Download
+---
-h2. Installing Buildr
+h2(#install). Installing Buildr
The easiest way to install Buildr is using the fabulous RubyGems package manager. Of course, you will need either Ruby or JRuby, and we recommend upgrading to the most recent version of RubyGems. If this sounds foreign to you, don't worry. We'll show you how to install Buildr on Linux, OS X, Windows and JRuby in the "Getting Started guide":getting_started.html, we even provide automated installation scripts.
@@ -12,7 +15,7 @@
The source code is included in both source and binary distribution, the Gem distribution expands the source code into your local Gem repository. That's in addition to getting the source code directly from "SVN":http://svn.apache.org/repos/asf/buildr or "GitHub":http://github.com/vic/buildr/tree/master. Learn more about working with source code and "living on the edge":contributing.html#living_on_the_edge.
-h2. Binaries and Source Code
+h2(#dist). Binaries and Source Code
h3. buildr 1.3.3-incubating (2008-10-08)
Copied: buildr/trunk/doc/extending.textile (from r752580, buildr/trunk/doc/pages/extending.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/extending.textile?p2=buildr/trunk/doc/extending.textile&p1=buildr/trunk/doc/pages/extending.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/extending.textile (original)
+++ buildr/trunk/doc/extending.textile Wed Mar 11 22:39:02 2009
@@ -1,6 +1,9 @@
-h1. Extending Buildr
+---
+layout: default
+title: Extending Buildr
+---
-h2. Organizing Tasks
+h2(#tasks). Organizing Tasks
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.
@@ -8,7 +11,7 @@
Compare this:
-{{{!ruby
+{% highlight ruby %}
file('derby.sql') do
REQUIRES = [
'org.apache.openjpa:openjpa-all:jar:0.9.7-incubating',
@@ -27,17 +30,17 @@
end
end
end
-}}}
+{% endhighlight %}
To this:
-{{{!ruby
+{% highlight ruby %}
file('derby.sql') do
mapping_tool :action=>'build', :sql=>task.name,
:properties=>_('src/main/sql/derby.xml'),
:classpath=>projects('store', 'utils')
end
-}}}
+{% endhighlight %}
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.
@@ -48,25 +51,25 @@
For individual task files, you can also use "Sake":http://errtheblog.com/post/6069 for system-wide Rake tasks deployment.
-h2. Creating Extensions
+h2(#extensions). Creating Extensions
The basic mechanism for extending projects in Buildr are Ruby modules. In fact, base features like compiling and testing are all developed in the form of modules, and then added to the core Project class.
A module defines instance methods that are then mixed into the project and become instance methods of the project. There are two general ways for extending projects. You can extend all projects by including the module in Project:
-{{{!ruby
+{% highlight ruby %}
class Project
include MyExtension
end
-}}}
+{% endhighlight %}
You can also extend a given project instance and only that instance by extending it with the module:
-{{{!ruby
+{% highlight ruby %}
define 'foo' do
extend MyExtension
end
-}}}
+{% endhighlight %}
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.
@@ -79,7 +82,7 @@
This example illustrates how to write a simple extension:
-{{{!ruby
+{% highlight ruby %}
module LinesOfCode
include Extension
@@ -114,35 +117,36 @@
class Buildr::Project
include LinesOfCode
end
-}}}
+{% endhighlight %}
+<!-- -->
-h2. Using Alternative Layouts
+h2(#layouts). Using Alternative Layouts
Buildr follows a common convention for project layouts: Java source files appear in @src/main/java@ and compile to @target/classes@, resources are copied over from @src/main/resources@ and so forth. Not all projects follow this convention, so it's now possible to specify an alternative project layout.
The default layout is available in @Layout.default@, and all projects inherit it. You can set @Layout.default@ to your own layout, or define a project with a given layout (recommended) by setting the @:layout@ property. Projects inherit the layout from their parent projects. For example:
-{{{!ruby
+{% highlight ruby %}
define 'foo', :layout=>my_layout do
...
end
-}}}
+{% endhighlight %}
A layout is an object that implements the @expand@ method. The easiest way to define a custom layout is to create a new @Layout@ object and specify mapping between names used by Buildr and actual paths within the project. For example:
-{{{!ruby
+{% highlight ruby %}
my_layout = Layout.new
my_layout[:source, :main, :java] = 'java'
my_layout[:source, :main, :resources] = 'resources'
-}}}
+{% endhighlight %}
Partial expansion also works, so you can specify the above layout using:
-{{{!ruby
+{% highlight ruby %}
my_layout = Layout.new
my_layout[:source, :main] = ''
-}}}
+{% endhighlight %}
If you need anything more complex, you can always subclass @Layout@ and add special handling in the @expand@ method, you'll find one such example in the API documentation.
@@ -158,7 +162,7 @@
All tasks are encouraged to use the same convention, and whenever possible, we recommend using the project's @path_to@ method to expand a list of symbols into a path, or use the appropriate path when available. For example:
-{{{!ruby
+{% highlight ruby %}
define 'bad' do
# This may not be the real target.
puts 'Compiling to ' + path_to('target/classes')
@@ -172,4 +176,5 @@
# This will work with different layouts.
package(:jar).include path_to(:source, :main, :etc, '*')
end
-}}}
+{% endhighlight %}
+<!-- -->
Copied: buildr/trunk/doc/getting_started.textile (from r752580, buildr/trunk/doc/pages/getting_started.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/getting_started.textile?p2=buildr/trunk/doc/getting_started.textile&p1=buildr/trunk/doc/pages/getting_started.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/getting_started.textile (original)
+++ buildr/trunk/doc/getting_started.textile Wed Mar 11 22:39:02 2009
@@ -1,6 +1,9 @@
-h1. Getting Started
+---
+layout: default
+title: Getting Started
+---
-h2. Installing Buildr
+h2(#installing). Installing Buildr
The installation instructions are slightly different for each operating system. Pick the one that best matches your operating system and target platform.
@@ -9,108 +12,108 @@
The current release of Buildr for Ruby may not work well with Java 6, only Java 1.5 or earlier. If you need to use Java 6, consider "Buildr for JRuby":#jruby.
-h3. Linux
+h3(#linux). Linux
To get started you will need a recent version of Ruby, Ruby Gems and build tools for compiling native libraries (@make@, @gcc@ and standard headers).
On *RedHat/Fedora* you can use yum to install Ruby and RubyGems, and then upgrade to the most recent version of RubyGems:
-{{{!sh
+{% highlight sh %}
$ sudo yum install ruby rubygems ruby-devel gcc
$ sudo gem update --system
-}}}
+{% endhighlight %}
On *Ubuntu* you have to install several packages:
-{{{!sh
+{% highlight sh %}
$ sudo apt-get install ruby-full ruby1.8-dev libopenssl-ruby build-essential
-}}}
+{% endhighlight %}
The Debian package for @rubygems@ will not allow you to install Buildr, so you need to install RubyGems from source:
-{{{!sh
+{% highlight sh %}
$ wget http://rubyforge.org/frs/download.php/38646/rubygems-1.2.0.tgz
$ tar xzf rubygems-1.2.0.tgz
$ cd rubygems-1.2.0
$ sudo ruby setup.rb
$ sudo ln -s /usr/bin/gem1.8 /usr/bin/gem
-}}}
+{% endhighlight %}
Before installing Buildr, please set the @JAVA_HOME@ environment variable to point to your JDK distribution. Next, use Ruby Gem to install Buildr:
-{{{!sh
+{% highlight sh %}
$ sudo env JAVA_HOME=$JAVA_HOME gem install buildr
-}}}
+{% endhighlight %}
To upgrade to a new version or install a specific version:
-{{{!sh
+{% highlight sh %}
$ sudo env JAVA_HOME=$JAVA_HOME gem update buildr
$ sudo env JAVA_HOME=$JAVA_HOME gem install buildr -v 1.3.4
-}}}
+{% endhighlight %}
You can also use this script "to install Buildr on Linux":scripts/install-linux.sh. This script will install Buildr or if already installed, upgrade to a more recent version. It will also install Ruby 1.8.6 if not already installed (using @yum@ or @apt-get@) and upgrage RubyGems to 1.0.1.
-h3. OS X
+h3(#osx). OS X
OS X 10.5 (Leopard) comes with a recent version of Ruby 1.8.6. OS X 10.4 (Tiger) includes an older version of Ruby, we recommend you first install Ruby 1.8.6 using MacPorts (@sudo port install ruby rb-rubygems@), Fink or the "Ruby One-Click Installer for OS X":http://rubyosx.rubyforge.org/.
We recommend you first upgrade to the latest version of Ruby gems:
-{{{!sh
+{% highlight sh %}
$ sudo gem update --system
-}}}
+{% endhighlight %}
Before installing Buildr, please set the @JAVA_HOME@ environment variable to point to your JDK distribution:
-{{{!sh
+{% highlight sh %}
$ export JAVA_HOME=/Library/Java/Home
-}}}
+{% endhighlight %}
To install Buildr:
-{{{!sh
+{% highlight sh %}
$ sudo env JAVA_HOME=$JAVA_HOME gem install buildr
-}}}
+{% endhighlight %}
To upgrade to a new version or install a specific version:
-{{{!sh
+{% highlight sh %}
$ sudo env JAVA_HOME=$JAVA_HOME gem update buildr
$ sudo env JAVA_HOME=$JAVA_HOME gem install buildr -v 1.3.4
-}}}
+{% endhighlight %}
You can also use this script "to install Buildr on OS X":scripts/install-osx.sh. This script will install Buildr or if already installed, upgrade to a more recent version. It will also install Ruby 1.8.6 if not already installed (using MacPorts) and upgrage RubyGems to 1.0.1.
-h3. Windows
+h3(#windows). Windows
If you don't already have Ruby installed, now is the time to do it. The easiest way to install Ruby is using the "one-click installer":http://rubyinstaller.rubyforge.org/.
We recommend you first upgrade to the latest version of Ruby gems:
-{{{!sh
+{% highlight sh %}
> gem update --system
-}}}
+{% endhighlight %}
Before installing Buildr, please set the @JAVA_HOME@ environment variable to point to your JDK distribution. Next, use Ruby Gem to install Buildr:
-{{{!sh
+{% highlight sh %}
> gem install buildr
-}}}
+{% endhighlight %}
Buildr uses several libraries that include native extensions. During installation it will ask you to pick a platform for these libraries. By selecting @mswin32@ it will download and install pre-compiled DLLs for these extensions.
To upgrade to a new version or install a specific version:
-{{{!sh
+{% highlight sh %}
> gem update buildr
> gem install buildr -v 1.3.4
-}}}
+{% endhighlight %}
-h3. JRuby
+h3(#jruby). JRuby
If you don't already have JRuby 1.1 or later installed, you can download it from the "JRuby site":http://dist.codehaus.org/jruby/.
@@ -118,24 +121,24 @@
For Linux and OS X:
-{{{!sh
+{% highlight sh %}
$ export PATH=$PATH:[path to JRuby]/bin:$JAVA_HOME/bin
$ jruby -S gem install buildr
-}}}
+{% endhighlight %}
For Windows:
-{{{!sh
+{% highlight sh %}
> set PATH=%PATH%;[path to JRuby]/bin;%JAVA_HOME%/bin
> jruby -S gem install buildr
-}}}
+{% endhighlight %}
To upgrade to a new version or install a specific version:
-{{{!sh
+{% highlight sh %}
$ jruby -S gem update buildr
$ jruby -S gem install buildr -v 1.3.4
-}}}
+{% endhighlight %}
You can also use this script "to install Buildr on JRuby":scripts/install-jruby.sh. This script will install Buildr or if already installed, upgrade to a more recent version. If necessary, it will also install JRuby 1.1 in @/opt/jruby@ and update the @PATH@ variable in @~/.bash_profile@ or @~/.profile@.
@@ -149,59 +152,51 @@
You can use JRuby and Ruby side by side, by running scripts with the @-S@ command line argument. For example:
-{{{!
+{% highlight sh %}
$ # with Ruby
$ ruby -S gem install buildr
$ ruby -S buildr
$ # with JRuby
$ jruby -S gem install buildr
$ jruby -S buildr
-}}}
+{% endhighlight %}
Run @buildr --version@ from the command line to find which version of Buildr you are using by default. If you see @(JRuby ...)@, Buildr is running on that version of JRuby.
-h2. Document Conventions
+h2(#conventions). Document Conventions
Lines that start with @$@ are command lines, for example:
-{{{!sh
+{% highlight sh %}
$ # Run Buildr
$ buildr
-}}}
+{% endhighlight %}
Lines that start with @=>@ show output from the console or the result of a method, for example:
-{{{!sh
+{% highlight sh %}
puts 'Hello world'
=> "Hello world"
-}}}
+{% endhighlight %}
And as you guessed, everything else is Buildfile Ruby or Java code. You can figure out which language is which.
-h2. Running Buildr
+h2(#running). Running Buildr
-You need a *Buildfile*, a build script that tells Buildr all about the projects it's building, what they contain, what to produce, and so on. The Buildfile resides in the root directory of your project. We'll talk more about it in "the next chapter":projects.html. If you don't already have one, ask Buildr to create it:
-
-{{{!sh
-$ buildr
-}}}
+You need a *Buildfile*, a build script that tells Buildr all about the projects it's building, what they contain, what to produce, and so on. The Buildfile resides in the root directory of your project. We'll talk more about it in "the next chapter":projects.html. If you don't already have one, ask Buildr to create it by running @buildr@.
p(tip). You'll notice that Buildr creates a file called @buildfile@. It's case sensitive, but Buildr will look for either @buildfile@ or @Buildfile@.
You use Buildr by running the @buildr@ command:
-{{{!sh
+{% highlight sh %}
$ buildr [options] [tasks] [name=value]
-}}}
-
-There are several options you can use, for a full list of options type:
+{% endhighlight %}
-{{{!sh
-$ buildr --help
-}}}
+There are several options you can use, for a full list of options type @buildr --help@:
|_. Option |_. Usage |
| @-f/--buildfile [file]@ | Specify the buildfile. |
@@ -216,12 +211,12 @@
You can tell Buildr to run specific tasks and the order to run them. For example:
-{{{!sh
+{% highlight sh %}
# Clean and rebuild
buildr clean build
# Package and install
buildr install
-}}}
+{% endhighlight %}
If you don't specify a task, Buildr will run the "@build@ task":building.html, compiling source code and running test cases. Running a task may run other tasks as well, for example, running the @install@ task will also run @package@.
@@ -229,38 +224,38 @@
For example:
-{{{!sh
+{% highlight sh %}
$ export JAVA_OPTS='-Xms1g -Xmx1g'
$ buildr TEST=no
-}}}
+{% endhighlight %}
-h2. Help Tasks
+h2(#help). Help Tasks
Buildr includes a number of informative tasks. Currently that number stands at two, but we'll be adding more tasks in future releases. These tasks report information from the Buildfile, so you need one to run them. For more general help (version number, command line arguments, etc) use @buildr --help@.
To start with, type:
-{{{!sh
+{% highlight sh %}
$ buildr help
-}}}
+{% endhighlight %}
You can list the name and description of all your projects using the @help:projects@ task. For example:
-{{{!sh
+{% highlight sh %}
$ buildr help:projects
killer-app # Code. Build. ??? Profit!
killer-app:teh-api # Abstract classes and interfaces
killer-app:teh-impl # All those implementation details
killer-app:la-web # What our users see
-}}}
+{% endhighlight %}
You are, of course, describing your projects for the sake of those who will maintain your code, right? To describe a project, or a task, call the @desc@ method before the project or task definition.
So next let's talk about "projects":projects.html.
-h2. Learning More
+h2(#more). Learning More
*Ruby* It pays to pick up Ruby as a second (or first) programming language. It's fun, powerful and slightly addictive. If you're interested in learning Ruby the language, a good place to start is "Programming Ruby: The Pragmatic Programmer's Guide":http://www.pragprog.com/titles/ruby/programming-ruby, fondly known as the _Pickaxe book_.
Copied: buildr/trunk/doc/index.textile (from r752580, buildr/trunk/doc/pages/index.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/index.textile?p2=buildr/trunk/doc/index.textile&p1=buildr/trunk/doc/pages/index.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/index.textile (original)
+++ buildr/trunk/doc/index.textile Wed Mar 11 22:39:02 2009
@@ -1,6 +1,9 @@
-h1. Welcome
+---
+layout: default
+title: Welcome
+---
-h2. What is Apache Buildr?
+h2(#what_is_apache_buildr). What is Apache Buildr?
Apache Buildr is a build system for Java-based applications, including support for Scala, Groovy and a growing number of JVM languages and tools. We wanted something that's simple and intuitive to use, so we only need to tell it what to do, and it takes care of the rest. But also something we can easily extend for those one-off tasks, with a language that's a joy to use. And of course, we wanted it to be fast, reliable and have outstanding dependency management.
@@ -20,7 +23,7 @@
So let's get started. You can "read the documentation online":getting_started.html, or "download the PDF":buildr.pdf.
-h2. Project News
+h2(#news). Project News
Check out "all that's new in Buildr 1.3.3":whats_new.html.
@@ -33,7 +36,7 @@
* Other features and bug fixes.
-h2. Legal Notices
+h2(#legal). Legal Notices
The Apache Software Foundation is a non-profit organization, consider "sponsoring":http://www.apache.org/foundation/sponsorship.html and check the "thanks":http://www.apache.org/foundation/thanks.html page.
Copied: buildr/trunk/doc/languages.textile (from r752580, buildr/trunk/doc/pages/languages.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/languages.textile?p2=buildr/trunk/doc/languages.textile&p1=buildr/trunk/doc/pages/languages.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/languages.textile (original)
+++ buildr/trunk/doc/languages.textile Wed Mar 11 22:39:02 2009
@@ -1,7 +1,10 @@
-h1. Languages
+---
+layout: default
+title: Languages
+---
-h2. Java
+h2(#java). Java
h3. Compiling Java
@@ -43,9 +46,9 @@
For example, to pass properties to the test case:
-{{{!ruby
+{% highlight ruby %}
test.using :properties=>{ :currency=>'USD' }
-}}}
+{% endhighlight %}
There are benefits to running test cases in separate VMs. The default forking mode is @:once@, and you can change it by setting the @:fork@ option.
@@ -58,28 +61,29 @@
In addition, you can get a consolidated XML or HTML report by running the @junit:report@ task. For example:
-{{{!sh
+{% highlight sh %}
$ buildr test junit:report test=all
$ firefox report/junit/html/index.html
-}}}
+{% endhighlight %}
The @junit:report@ task generates a report from all tests run so far. If you run tests in a couple of projects, it will generate a report only for these two projects. The example above runs tests in all the projects before generating the reports.
You can use the @build.yaml@ settings file to specify a particular version of JUnit or JMock. For example, to force your build to use JUnit version 4.4 and JMock 2.0:
-{{{!yaml
+{% highlight yaml %}
junit: 4.4
jmock: 2.0
-}}}
+{% endhighlight %}
+<!-- -->
h4. TestNG
You can use "TestNG":http://testng.org instead of JUnit. To select TestNG as the test framework, add this to your project:
-{{{!ruby
+{% highlight ruby %}
test.using :testng
-}}}
+{% endhighlight %}
Like all other options you can set with @test.using@, it affects the projects and all its sub-projects, so you only need to do this once at the top-most project to use TestNG throughout. You can also mix TestNG and JUnit by setting different projects to use different frameworks, but you can't mix both frameworks in the same project. (And yes, @test.using :junit@ will switch a project back to using JUnit)
@@ -93,9 +97,10 @@
You can use the @build.yaml@ settings file to specify a particular version of TestNG, for example, to force your build to use TestNG 5.7:
-{{{!yaml
+{% highlight yaml %}
testng: 5.7
-}}}
+{% endhighlight %}
+<!-- -->
h4. JBehave
@@ -106,9 +111,9 @@
This framework will search for the following patterns under your project:
-{{{
+{% highlight text %}
src/spec/java/**/*Behaviour.java
-}}}
+{% endhighlight %}
Supports the following options:
@@ -118,26 +123,27 @@
You can use the @build.yaml@ settings file to specify a particular version of JBehave, for example, to force your build to use JBehave 1.0.1:
-{{{!yaml
+{% highlight yaml %}
jbehave: 1.0.1
-}}}
+{% endhighlight %}
+<!-- -->
-h2. Scala
+h2(#scala). Scala
Before using Scala features, you must first set the @SCALA_HOME@ environment variable to point to the root of your Scala distribution.
On Windows:
-{{{!sh
+{% highlight sh %}
> set SCALA_HOME=C:\Path\To\Scala-2.7.1
-}}}
+{% endhighlight %}
On Linux and other Unix variants,
-{{{!sh
+{% highlight sh %}
> export SCALA_HOME=/path/to/scala-2.7.1
-}}}
+{% endhighlight %}
The @SCALA_HOME@ base directory should be such that Scala core libraries are located directly under the "lib" subdirectory, and Scala scripts are under the "bin" directory.
@@ -181,9 +187,9 @@
Scala testing is automatically enabled if you have any @.scala@ source files under @src/test/scala@. If you are not using this convention, you can explicit set the test framework by doing,
-{{{!ruby
+{% highlight ruby %}
test.using(:scalatest)
-}}}
+{% endhighlight %}
The @:scalatest@ test framework handles ScalaTest, Specs and ScalaCheck therefore all 3 frameworks may be used within the same project.
@@ -193,18 +199,18 @@
A very simplistic test class might look like,
-{{{!scala
+{% highlight scala %}
class MySuite extends org.scalatest.FunSuite {
test("addition") {
val sum = 1 + 1
assert(sum === 2)
}
}
-}}}
+{% endhighlight %}
You can also pass properties to your tests by doing @test.using :properties => { 'name'=>'value' }@, and by overriding the @Suite.runTests@ method in a manner similar to:
-{{{!scala
+{% highlight scala %}
import org.scalatest._
class PropertyTestSuite extends FunSuite {
@@ -223,7 +229,8 @@
includes, excludes, properties)
}
}
-}}}
+{% endhighlight %}
+<!-- -->
h4. Specs
@@ -231,7 +238,7 @@
A simple specification might look like this:
-{{{!scala
+{% highlight scala %}
import org.specs._
import org.specs.runner._
@@ -242,13 +249,14 @@
}
}
}
-}}}
+{% endhighlight %}
+<!-- -->
h4. ScalaCheck
You may use ScalaCheck inside ScalaTest- and Specs-inherited classes. Here is an example illustrating checks inside a ScalaTest suite,
-{{{!scala
+{% highlight scala %}
import org.scalatest.prop.PropSuite
import org.scalacheck.Arbitrary._
import org.scalacheck.Prop._
@@ -267,18 +275,19 @@
(a: List[Int], b: List[Int]) => a.size + b.size == (a ::: b).size
)
}
-}}}
+{% endhighlight %}
+<!-- -->
-h2. Groovy
+h2(#groovy). Groovy
h3. Compiling Groovy
Before using the Groovy compiler, you must first require it on your buildfile:
-{{{!ruby
+{% highlight ruby %}
require 'buildr/java/groovyc'
-}}}
+{% endhighlight %}
Once loaded, the groovyc compiler will be automatically selected if any .groovy source files are found under @src/main/groovy@ directory, compiling them by default into the @target/classes@ directory.
@@ -319,10 +328,10 @@
This framework will search for the following patterns under your project:
-{{{
+{% highlight text %}
src/spec/groovy/**/*Behavior.groovy
src/spec/groovy/**/*Story.groovy
-}}}
+{% endhighlight %}
Supports the following options:
@@ -332,7 +341,7 @@
| @:format@ | Report format, either @:txt@ or @:xml@ |
-h2. Ruby
+h2(#ruby). Ruby
h3. Testing with Ruby
@@ -346,9 +355,10 @@
You can use the @build.yaml@ settings file to specify a particular version of JRuby (defaults to @1.1.4@). For example:
-{{{!yaml
+{% highlight yaml %}
jruby: 1.1.3
-}}}
+{% endhighlight %}
+<!-- -->
h4. RSpec
@@ -358,9 +368,9 @@
This framework will search for the following patterns under your project:
-{{{
+{% highlight text %}
src/spec/ruby/**/*_spec.rb
-}}}
+{% endhighlight %}
Supports the following options:
@@ -381,9 +391,9 @@
You can use the @build.yaml@ settings file to specify a particular version of JtestR (defaults to @0.3.1@). For example:
-{{{!yaml
+{% highlight yaml %}
jtestr: 0.3.1
-}}}
+{% endhighlight %}
To customize TestNG/JUnit versions refer to their respective section.
Copied: buildr/trunk/doc/mailing_lists.textile (from r752580, buildr/trunk/doc/pages/mailing_lists.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/mailing_lists.textile?p2=buildr/trunk/doc/mailing_lists.textile&p1=buildr/trunk/doc/pages/mailing_lists.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/mailing_lists.textile (original)
+++ buildr/trunk/doc/mailing_lists.textile Wed Mar 11 22:39:02 2009
@@ -1,4 +1,7 @@
-h1. Mailing Lists
+---
+layout: default
+title: Mailing Lists
+---
|_. users |_. For developers working with Buildr |
Copied: buildr/trunk/doc/more_stuff.textile (from r752580, buildr/trunk/doc/pages/more_stuff.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/more_stuff.textile?p2=buildr/trunk/doc/more_stuff.textile&p1=buildr/trunk/doc/pages/more_stuff.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/more_stuff.textile (original)
+++ buildr/trunk/doc/more_stuff.textile Wed Mar 11 22:39:02 2009
@@ -1,7 +1,10 @@
-h1. More Stuff
+---
+layout: default
+title: More Stuff
+---
-h2. Using Gems
+h2(#gems). Using Gems
The purpose of the buildfile is to define your projects, and the various tasks and functions used for building them. Some of these are specific to your projects, others are more general in nature, and you may want to share them across projects.
@@ -17,7 +20,7 @@
Use the @build.yaml@ file to specify these dependencies (see "Build Settings":settings_profiles.html#build_settings for more information), for example:
-{{{!yaml
+{% highlight yaml %}
# This project requires the following gems
gems:
# Suppose we want to notify developers when testcases fail.
@@ -25,7 +28,7 @@
# we test with ruby mock objects
- mocha
- ci_reporter
-}}}
+{% endhighlight %}
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.
@@ -39,28 +42,28 @@
Most gems include documentation that you can access in several forms. You can use the @ri@ command line tool to find out more about a class, module or specific method. For example:
-{{{!sh
+{% highlight sh %}
$ ri Buildr::Jetty
$ ri Buildr::Jetty.start
-}}}
+{% endhighlight %}
You can also access documentation from a Web browser by running @gem server@ and pointing your browser to "http://localhost:8808":http://localhost:8808. Note that after installing a new gem, you will need to restart the gem server to see its documentation.
-h2. Using Java Libraries
+h2(#java). Using Java Libraries
Buildr runs along side a JVM, using either RJB or JRuby. The Java module allows you to access Java classes and create Java objects.
Java classes are accessed as static methods on the @Java@ module, for example:
-{{{!ruby
+{% highlight ruby %}
str = Java.java.lang.String.new('hai!')
str.toUpperCase
=> 'HAI!'
Java.java.lang.String.isInstance(str)
=> true
Java.com.sun.tools.javac.Main.compile(args)
-}}}
+{% endhighlight %}
The @classpath@ 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.
@@ -68,9 +71,9 @@
For example, Ant is loaded as follows:
-{{{!ruby
+{% highlight ruby %}
Java.classpath << 'org.apache.ant:ant:jar:1.7.0'
-}}}
+{% endhighlight %}
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 @Java.load@ before accessing any Java classes to give Buildr a chance to load the libraries specified in the classpath.
@@ -82,39 +85,39 @@
# Check on a clean build with empty local repository.
-h2. BuildrServer
+h2(#buildr-server). BuildrServer
Buildr provides an addon that allows you start a "dRuby":http://www.ruby-doc.org/stdlib/libdoc/drb/rdoc/index.html server hosting a buildfile, so that you can later invoke tasks on it without having to load the complete buildr runtime again.
Usage:
-{{{!sh
+{% highlight sh %}
buildr -r buildr/drb drb:start
-}}}
+{% endhighlight %}
To stop the BuildrServer simply use Ctrl+C or kill the process.
Once the server has been started you can invoke tasks using a simple script:
-{{{!ruby
+{% highlight ruby %}
#!/usr/bin/env ruby
require 'rubygems'
require 'buildr/drb'
Buildr::DRbApplication.run
-}}}
+{% endhighlight %}
Save this script as @dbuildr@, make it executable and use it to invoke tasks.
-{{{!sh
+{% highlight sh %}
$ dbuildr clean compile
-}}}
+{% endhighlight %}
@dbuildr@ 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.
-h3. Nailgun
+h3(#nailgun). Nailgun
"Nailgun":http://www.martiansoftware.com/nailgun/index.html is a client, protocol, and server for running Java programs from the command line without incurring the JVM startup overhead. Nailgun integration is available only when running Buildr within JRuby.
@@ -123,20 +126,22 @@
Start the BuildrServer by executing
-{{{!sh
+{% highlight sh %}
$ jruby -S buildr -rbuildr/nailgun nailgun:start
-}}}
+{% endhighlight %}
To stop the BuildrServer simply use Ctrl+C or kill the process.
Once the server has been started you can invoke tasks using the nailgun client
installed on @$JRUBY_HOME/tool/nailgun/ng@
-{{{!sh
+{% highlight sh %}
$ ng clean compile
-}}}
+{% endhighlight %}
+<!-- -->
-h2. Growl, Qube
+
+h2(#growl). Growl, Qube
For OS X users, Buildr supports "Growl":http://growl.info/ out of the box to send "completed and "failed" notifications to the user.
@@ -147,7 +152,7 @@
Here is an example using these extension points to send notifications using "Qube":http://launchpad.net/qube:
-{{{!ruby
+{% highlight ruby %}
# Send notifications using Qube
notify = lambda do |type, title, message|
param = case type
@@ -164,17 +169,17 @@
Buildr.application.on_failure do |title, message, ex|
notify['failed', title, message]
end
-}}}
+{% endhighlight %}
You can place this code inside @buildr.rb@ in your home directory.
-h2. Eclipse, IDEA
+h2(#eclipse_idea). Eclipse, IDEA
If you're using Eclipse, you can generate @.classpath@ and @.project@ from your Buildfile and use them to create a project in your workspace:
-{{{!sh
+{% highlight sh %}
$ buildr eclipse
-}}}
+{% endhighlight %}
The @eclipse@ task will generate a @.classpath@ and @.project@ 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.
@@ -182,15 +187,15 @@
To have your libraries' source code available in Eclipse, run:
-{{{!sh
+{% highlight sh %}
$ buildr artifacts:sources
-}}}
+{% endhighlight %}
If you prefer IntelliJ IDEA, you can always:
-{{{!sh
+{% highlight sh %}
$ buildr idea
-}}}
+{% endhighlight %}
It will generate a @.iml@ file for every project (or subproject) and a @.ipr@ that you can directly open for the root project. To allow IntelliJ Idea to resolve external dependencies properly, you will need to add a @M2_REPO@ variable pointing to your Maven2 repository directory (@Settings / Path Variables@).
@@ -199,64 +204,67 @@
Also, check out the "Buildr plugin for IDEA":http://www.digitalsanctum.com/buildr-plug-in/ (IDEA 7 and later). Once installed, open your project with IDEA. If IDEA 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, IDEA will show the results in the Buildr Output window.
-h2. Cobertura, Emma, JDepend
+h2(#cobertura_emma_jdepend). Cobertura, Emma, JDepend
You can use "Cobertura":http://cobertura.sourceforge.net/ or "Emma":http://emma.sourceforge.net/ to instrument your code, run the tests and create a test coverage report in either HTML or XML format.
There are two tasks for each tool, both of which generate a test coverage report in the @reports/cobertura@ (respectively @reports/emma@) directory. For example:
-{{{!sh
+{% highlight sh %}
$ buildr test cobertura:html
-}}}
+{% endhighlight %}
As you can guess, the other tasks are @cobertura:xml@, @emma:html@ and @emma:xml@.
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.
-{{{!sh
+{% highlight sh %}
$ buildr subModule:cobertura:html
-}}}
+{% endhighlight %}
Each project can specify which classes to include or exclude from cobertura instrumentation by giving a class-name regexp to the @cobertura.include@ or @cobertura.exclude@ methods:
-{{{!ruby
+{% highlight ruby %}
define 'someModule' do
- cobertura.include 'some.package.*'
- cobertura.include /some.(foo|bar).*/
+ cobertura.include 'some.package.==*=='
+ cobertura.include /some.(foo|bar).==*==/
cobertura.exclude 'some.foo.util.SimpleUtil'
- cobertura.exclude /*.Const(ants)?/i
+ cobertura.exclude /==*==.Const(ants)?/i
end
-}}}
+{% endhighlight %}
Emma has @include@ and @exclude@ methods too, but they take glob patterns instead of regexps.
You can use "JDepend":http://clarkware.com/software/JDepend.html on to generate design quality metrics. There are three tasks this time, the eye candy one:
-{{{!sh
+{% highlight sh %}
$ buildr jdepend:swing
-}}}
+{% endhighlight %}
The other two tasks are @jdepend:text@ and @jdepend:xml@.
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:
-{{{!ruby
+{% highlight ruby %}
require 'buildr/java/cobertura'
require 'buildr/java/emma'
require 'buildr/jdepend'
-}}}
+{% endhighlight %}
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 @buildr.rb@ file in your home directory.
Another option is to require it from the command line (@--require@ or @-r@), for example:
-{{{!sh
+<notextile>
+{% highlight sh %}
$ buildr --require buildr/jdepend jdepend:swing
$ buildr -rbuildr/java/cobertura cobertura:html
-}}}
+{% endhighlight %}
+</notextile>
+<!-- -->
-h2. Anything Ruby Can Do
+h2(#anything_ruby). Anything Ruby Can Do
Buildr is Ruby code. That's an implementation detail for some, but a useful features for others. You can use Ruby to keep your build scripts simple and DRY, tackle ad hoc tasks and write reusable features without the complexity of "plugins".
@@ -264,17 +272,17 @@
You can use Ruby to perform ad hoc tasks. For example, Buildr doesn't have any pre-canned task for setting file permissions. But Ruby has a method for that, so it's just a matter of writing a task:
-{{{!ruby
-bins = file('target/bin'=>FileList[_('src/main/dist/bin/*')]) do |task|
+{% highlight ruby %}
+bins = file('target/bin'=>FileList[_('src/main/dist/bin/==*==')]) do |task|
mkpath task.name
cp task.prerequisites, task.name
- chmod 0755, FileList[task.name + '/*.sh'], :verbose=>false
+ chmod 0755, FileList[task.name + '/==*==.sh'], :verbose=>false
end
-}}}
+{% endhighlight %}
You can use functions to keep your code simple. For example, in the ODE 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:
-{{{!ruby
+{% highlight ruby %}
def distro(project, id)
project.package(:zip, :id=>id).path("#{id}-#{version}").tap do |zip|
zip.include meta_inf + ['RELEASE_NOTES', 'README'].map { |f| path_to(f) }
@@ -290,25 +298,25 @@
yield zip
end
end
-}}}
+{% endhighlight %}
And then use it in the project definition:
-{{{!ruby
+{% highlight ruby %}
define 'distro-axis2' do
parent.distro(self, "#{parent.id}-war") { |zip|
zip.include project('ode:axis2-war').package(:war), :as=>'ode.war' }
end
-}}}
+{% endhighlight %}
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:
-{{{!ruby
+{% highlight ruby %}
sources = projects.map { |prj| prj.compile.sources.
map { |src| FileList["#{src}/**/*.java"] } }.flatten
puts "There are #{source.size} source files"
lines = sources.inject(0) { |lines, src| lines += File.readlines(src).size }
puts "That contain #{lines} lines"
-}}}
-
+{% endhighlight %}
+<!-- -->