buildr 1.3.3 → 1.3.4

data/DISCLAIMER

@@ -1,7 +0,0 @@
-Apache Buildr is an effort undergoing incubation at The Apache Software
-Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of
-all newly accepted projects until a further review indicates that the
-infrastructure, communications, and decision making process have stabilized in
-a manner consistent with other successful ASF projects. While incubation status
-is not necessarily a reflection of the completeness or stability of the code,
-it does indicate that the project has yet to be fully endorsed by the ASF.

data/doc/pages/download.textile

@@ -1,51 +0,0 @@
-h1. Download
-
-
-h2.  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.
-
-The *official Apache distribution* consists of the digitally signed binaries (gems) and source packages "available below":#binaries_and_source_code.  To install these binaries, you must first download them to disk and then install them using the @gem install@ command (or @rake install@ for a source distribution).
-
-In addition, contributors to this project maintain a separate distribution over on "RubyForge":http://rubyforge.org/projects/buildr.  Using this distribution, you're able to install Buildr directly from the remote gem repository and to automatically upgrade when a new release comes out.  The RubyForge distribution is *not* an official Apache distribution.
-
-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/incubator/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
-
-h3. buildr 1.3.2-incubating (2008-07-18)
-
-|_. Package |_. MD5 Checksum |_. PGP |
-| "buildr-1.3.2-incubating.gem":http://www.apache.org/dist/incubator/buildr/1.3.2-incubating/buildr-1.3.2-incubating.gem | "225504bc195334c4eb9d6dec814d9db1":http://www.apache.org/dist/incubator/buildr/1.3.2-incubating/buildr-1.3.2-incubating.gem.md5 | "Sig":http://www.apache.org/dist/incubator/buildr/1.3.2-incubating/buildr-1.3.2-incubating.gem.asc |
-| "buildr-1.3.2-java-incubating.gem":http://www.apache.org/dist/incubator/buildr/1.3.2-incubating/buildr-1.3.2-java-incubating.gem | "d7d8394c7aed887987be0e813e1e4cee":http://www.apache.org/dist/incubator/buildr/1.3.2-incubating/buildr-1.3.2-java-incubating.gem.md5 | "Sig":http://www.apache.org/dist/incubator/buildr/1.3.2-incubating/buildr-1.3.2-java-incubating.gem.asc |
-| "buildr-1.3.2-incubating.tgz":http://www.apache.org/dist/incubator/buildr/1.3.2-incubating/buildr-1.3.2-incubating.tgz | "611e97df1bc76382ecbe6b60e9340f2b":http://www.apache.org/dist/incubator/buildr/1.3.2-incubating/buildr-1.3.2-incubating.tgz.md5 | "Sig":http://www.apache.org/dist/incubator/buildr/1.3.2-incubating/buildr-1.3.2-incubating.tgz.asc |
-| "buildr-1.3.2-incubating.zip":http://www.apache.org/dist/incubator/buildr/1.3.2-incubating/buildr-1.3.2-incubating.zip | "d65d20005f603338c0aedd4f17d0bc90":http://www.apache.org/dist/incubator/buildr/1.3.2-incubating/buildr-1.3.2-incubating.zip.md5 | "Sig":http://www.apache.org/dist/incubator/buildr/1.3.2-incubating/buildr-1.3.2-incubating.zip.asc |
-
-p>. ("Release signing keys":http://www.apache.org/dist/incubator/buildr/1.3.2-incubating/KEYS)
-
-
-
-h3. buildr 1.3.1-incubating (2008-05-19)
-
-|_. Package |_. MD5 Checksum |_. PGP |
-| "buildr-1.3.1-incubating.gem":http://www.apache.org/dist/incubator/buildr/1.3.1-incubating/buildr-1.3.1-incubating.gem | "476436429b9a6c4ed178009ba17dd724":http://www.apache.org/dist/incubator/buildr/1.3.1-incubating/buildr-1.3.1-incubating.gem.md5 | "Sig":http://www.apache.org/dist/incubator/buildr/1.3.1-incubating/buildr-1.3.1-incubating.gem.asc |
-| "buildr-1.3.1-java-incubating.gem":http://www.apache.org/dist/incubator/buildr/1.3.1-incubating/buildr-1.3.1-java-incubating.gem | "7af37acc10621b18d4b870119c36d998":http://www.apache.org/dist/incubator/buildr/1.3.1-incubating/buildr-1.3.1-java-incubating.gem.md5 | "Sig":http://www.apache.org/dist/incubator/buildr/1.3.1-incubating/buildr-1.3.1-java-incubating.gem.asc |
-| "buildr-1.3.1-incubating.tgz":http://www.apache.org/dist/incubator/buildr/1.3.1-incubating/buildr-1.3.1-incubating.tgz | "ad6694416fc2e6eb22ab1042dcc41411":http://www.apache.org/dist/incubator/buildr/1.3.1-incubating/buildr-1.3.1-incubating.tgz.md5 | "Sig":http://www.apache.org/dist/incubator/buildr/1.3.1-incubating/buildr-1.3.1-incubating.tgz.asc |
-| "buildr-1.3.1-incubating.zip":http://www.apache.org/dist/incubator/buildr/1.3.1-incubating/buildr-1.3.1-incubating.zip | "0470349978b93e645ca2e9607e304ed1":http://www.apache.org/dist/incubator/buildr/1.3.1-incubating/buildr-1.3.1-incubating.zip.md5 | "Sig":http://www.apache.org/dist/incubator/buildr/1.3.1-incubating/buildr-1.3.1-incubating.zip.asc |
-
-p>. ("Release signing keys":http://www.apache.org/dist/incubator/buildr/1.3.1-incubating/KEYS)
-
-
-h3. buildr 1.3.0-incubating (2008-05-01)
-
-|_. Package |_. MD5 Checksum |_. PGP |
-| "buildr-1.3.0-incubating.gem":http://www.apache.org/dist/incubator/buildr/1.3.0-incubating/buildr-1.3.0-incubating.gem | "37758d0a8dabc570799b0a58d23d19f0":http://www.apache.org/dist/incubator/buildr/1.3.0-incubating/buildr-1.3.0-incubating.gem.md5 | "Sig":http://www.apache.org/dist/incubator/buildr/1.3.0-incubating/buildr-1.3.0-incubating.gem.asc |
-| "buildr-1.3.0-java-incubating.gem":http://www.apache.org/dist/incubator/buildr/1.3.0-incubating/buildr-1.3.0-java-incubating.gem | "6a3a86740077f739c111514e0e2b9e06":http://www.apache.org/dist/incubator/buildr/1.3.0-incubating/buildr-1.3.0-java-incubating.gem.md5 | "Sig":http://www.apache.org/dist/incubator/buildr/1.3.0-incubating/buildr-1.3.0-java-incubating.gem.asc |
-| "buildr-1.3.0-incubating.tgz":http://www.apache.org/dist/incubator/buildr/1.3.0-incubating/buildr-1.3.0-incubating.tgz | "acd84ad8c5031962e65b0036f3bc2e76":http://www.apache.org/dist/incubator/buildr/1.3.0-incubating/buildr-1.3.0-incubating.tgz.md5 | "Sig":http://www.apache.org/dist/incubator/buildr/1.3.0-incubating/buildr-1.3.0-incubating.tgz.asc |
-| "buildr-1.3.0-incubating.zip":http://www.apache.org/dist/incubator/buildr/1.3.0-incubating/buildr-1.3.0-incubating.zip | "d85945f05efd0e512e6d769e3dd1cc98":http://www.apache.org/dist/incubator/buildr/1.3.0-incubating/buildr-1.3.0-incubating.zip.md5 | "Sig":http://www.apache.org/dist/incubator/buildr/1.3.0-incubating/buildr-1.3.0-incubating.zip.asc |
-
-p>. ("Release signing keys":http://www.apache.org/dist/incubator/buildr/1.3.0-incubating/KEYS)
-
-
-p(note). When downloading from files please check the "md5sum":http://www.apache.org/dev/release-signing#md5 and verify the "OpenPGP":http://www.apache.org/dev/release-signing#openpgp compatible signature from the main Apache site. This "KEYS":http://www.apache.org/dist/incubator/buildr/KEYS file contains the public keys used for signing releases. It is recommended that (when possible) a web of trust is used to confirm the identity of these keys. For more information, please see the "Apache Release FAQ":http://www.apache.org/dev/release.html.

data/doc/pages/index.textile

@@ -1,42 +0,0 @@
-h1. Welcome
-
-h2.  What is Buildr?
-
-Buildr is a build system for Java applications.  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.
-
-Here's what we got:
-
-* A simple way to specify projects, and build large projects out of smaller sub-projects.
-* Pre-canned tasks that require the least amount of configuration, keeping the build script DRY and simple.
-* Compiling, copying and filtering resources, JUnit/TestNG test cases, APT source code generation, Javadoc and more.
-* A dependency mechanism that only builds what has changed since the last release.
-* A drop-in replacement for Maven 2.0, Buildr uses the same file layout, artifact specifications, local and remote repositories.
-* All your Ant tasks belong to us! Anything you can do with Ant, you can do with Buildr.
-* No overhead for building "plugins" or configuration. Just write new tasks or functions.
-* Buildr is Ruby all the way down.  No one-off task is too demanding when you write code using variables, functions and objects.
-* Simple way to upgrade to new versions.
-* Did we mention fast?
-
-So let's get started.  You can "read the documentation online":getting_started.html, or "download the PDF":buildr.pdf.
-
-
-h2.  News
-
-Check out "all that's new in Buildr 1.3.3":whats_new.html.
-
-* Buildr 1.3 now runs on JRuby 1.1 and Ruby 1.8.6.
-* Support for building Scala and Groovy projects.
-* Behavior-Driven Development frameworks (RSpec, JBehave, etc).
-* Profiles and build.yml settings file.
-* New API for accessing Java libraries.
-* More documentation.
-* Other features and bug fixes.
-
-
-h2.  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.
-
-Apache Buildr is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
-
-"ColorCons":http://www.mouserunner.com/Spheres_ColoCons1_Free_Icons.html, copyright of Ken Saunders.  "DejaVu fonts":http://dejavu.sourceforge.net, copyright of Bitstream, Inc.

data/doc/pages/mailing_lists.textile

@@ -1,17 +0,0 @@
-h1. Mailing Lists
-
-
-|_. buildr-user |_. For developers working with Buildr |
-| Post          | "buildr-user@incubator.apache.org":mailto:buildr-user@incubator.apache.org |
-| Browse        | "buildr-user archives":http://mail-archives.apache.org/mod_mbox/incubator-buildr-user/ |
-| Subscribe     | "buildr-user-subscribe@incubator.apache.org":mailto:buildr-user-subscribe@incubator.apache.org |
-| Unsubscribe   | "buildr-user-unsubscribe@incubator.apache.org":mailto:buildr-user-unsubscribe@incubator.apache.org |
-|_. buildr-dev |_. For development of Buildr itself |
-| Post          | "buildr-dev@incubator.apache.org":mailto:buildr-dev@incubator.apache.org |
-| Browse        | "buildr-dev archives":http://mail-archives.apache.org/mod_mbox/incubator-buildr-dev/ |
-| Subscribe     | "buildr-dev-subscribe@incubator.apache.org":mailto:buildr-dev-subscribe@incubator.apache.org |
-| Unsubscribe   | "buildr-dev-unsubscribe@incubator.apache.org":mailto:buildr-dev-unsubscribe@incubator.apache.org |
-|_. buildr-commits |_. Commit messages and JIRA status |
-| Subscribe     | "buildr-commits-subscribe@incubator.apache.org":mailto:buildr-commits-subscribe@incubator.apache.org |
-| Unsubscribe   | "buildr-commits-unsubscribe@incubator.apache.org":mailto:buildr-commits-unsubscribe@incubator.apache.org |
-| Browse        | "buildr-commits archives":http://mail-archives.apache.org/mod_mbox/incubator-buildr-commits/ |

data/doc/pages/recipes.textile

@@ -1,103 +0,0 @@
-h1. Recipes
-
-Commond recipes for Buildr, collected from the mailing list.
-
-
-h2.  Creating a classpath
-
-For Java, the classpath argument is simply a list of paths joined with an OS-specific path separator:
-
-{{{!ruby
-cp = paths.join(File::PATH_SEPARATOR)
-}}}
-
-This assumes @paths@ points to files and/or directories, but what if you have a list of artifact specifications?  You can turn those into file names in two steps.  First, use @artifacts@ to return a list of file tasks that point to the local repository:
-
-{{{!ruby
-tasks = Buildr.artifacts(specs)
-}}}
-
-Next, map that list of tasks into list of file names (essentially calling @name@ on each task):
-
-{{{!ruby
-paths = tasks.map(&:name)
-}}}
-
-This works as long as the artifacts are already in your local repository, otherwise they can't be found, but you can ask Buildr to download them by calling @invoke@ on each of these tasks:
-
-{{{!ruby
-tasks = Buildr.artifacts(specs).each(&:invoke)
-}}}
-
-So let's roll this all into a single line:
-
-{{{!ruby
-cp = Buildr.artifacts(specs).each(&:invoke).map(&:name).join(File::PATH_SEPARATOR)
-}}}
-
-
-h2.  Keeping your Profiles.yaml file DRY
-
-YAML allows you to use anchors (@&@), similar to ID attributes in XML, and reference them later on (@*@).  For example, if you have two profiles that are identical, you can tell YAML that one is an alias for the other:
-
-{{{!yaml
-development: &common
-  db: oracle
-  port: 8080
-test: *common
-production: *common
-}}}
-
-If you have two elements that are almost identical, you can merge the values of one element into another (@<<@), for example:
-
-{{{!yaml
-development: &common
-  db: hsql
-  jdbc: hsqldb:mem:devdb
-test:
-  <<: *common
-  jdbc: hsqldb:file:testdb
-}}}
-
-
-h2.  Speeding JRuby
-
-When using JRuby you will notice that Buildr takes a few seconds to start up. To speed it up, we recommend switching to Java 1.6 and running the JVM in client mode:
-
-{{{!
-$ export JAVA_OPTS=-client
-}}}
-
-
-h2.  Continuous Integration with Atlassian Bamboo
-
-This recipe outlines how to configure a new Bamboo project to use Buildr.  The following steps assume that you have logged-on to Bamboo as an Administrator.
-
-*1. Configure a Builder*
-
-* Select the Administration tab from the Bamboo toolbar.
-* Select the Builders area (first option) from the Administration menu.
-* Using the Add Builder dialog, configure a custom builder for Buildr with the following options:
-** Label: @buildr@
-** Type:  @Custom Command@
-** Path:  @/path/to/buildr@ (typically "/usr/bin/buildr")
-
-*2. Create a Plan*
-
-* Select the Create Plan tab from the Bamboo toolbar to enter the Create Plan wizard.
-* In "1. Plan Details", define your build plan including project name, project key, build plan name and build plan key.
-* In "2. Source Repository", specify your source code repository settings (CVS or SVN).
-* In "3. Builder Configuration", specify the "buildr" builder that you defined above, along with the following:
-** Argument: @"test=all"@ (ensures that all tests are run through even if failures are encountered)
-** Test Results Directory: @"**/reports/junit/*.xml"@ (or your path to test results, if different).
-* The remaining wizard sections may be either skipped or configured with your preferred settings.
-
-*3. Trigger a Build*
-
-A build should occur automatically at the point of project creation. It can also be manually triggered at any time
-
-* Navigate to the project summary page (located at: @http://YOUR_BAMBOO_URL/browse/PROJECTKEY-YOURPLAN@).
-* Click on the small arrow to the left of the label "Build Actions"
-* Select "Checkout and Build" from the pop-up menu to force a build.
-
-The project page will contain full status information for previous builds and the results tabs will integrate the results from your JUnit tests.

data/doc/pages/troubleshooting.textile

@@ -1,103 +0,0 @@
-h1. Troubleshooting
-
-Common troubleshooting tips collected from the mailing list.
-
-
-h2.  Running out of heap space
-
-You can give the JVM more heap space by setting the @JAVA_OPTS@ environment variables.  This environment variable provides arguments for staring the JVM. For example, to set the heap space to 1GB:
-
-{{{!sh
-$ export "JAVA_OPTS=-Xms1g -Xmx1g"
-$ buildr compile
-}}}
-
-If you're sharing the build with other developers, you'll want to specify these options in the Buildfile itself.  You can set the environment variable within the Buildfile, but make sure to do so at the very top of the Buildfile.
-
-For example:
-
-{{{!ruby
-ENV['JAVA_OPTS'] = '-Xms1g -Xmx1g'
-}}}
-
-
-h2.  RJB fails to compile
-
-On Linux, BSD and Cygwin, RJB locates the JDK headers files -- which it uses to compile a native C extension -- based on the @JAVA_HOME@ environment variable. Make sure @JAVA_HOME@ points to the JDK, not JRE.
-
-If you are using @sudo gem install@, note that some environments do not pass the @JAVA_HOME@ environment variable over to @sudo@.  To get around this, run @gem@ with the @env JAVA_HOME=$JAVA_HOME@ option:
-
-{{{!sh
-$ sudo env JAVA_HOME=$JAVA_HOME gem install buildr
-}}}
-
-
-h2.  Segmentation Fault when running Java code
-
-This is most likely a JVM inconsistency, for example, when part of the RJB library uses JDK 1.6, the other part uses JDK 1.5.
-
-During installation RJB builds a native C extension using header files supplied by the JVM, and compiles a Java bridge class using the Javac.  It is possible for RJB to use two different versions of the JVM, for example, if @JAVA_HOME@ points to JDK 1.5, but @/usr/bin/javac@ points to JDK 1.6.
-
-Make sure @JAVA_HOME@ and @/usr/bin/javac@ both point to the same JDK:
-
-{{{!sh
-echo $JAVA_HOME
-ls -l /usr/bin/javac
-}}}
-
-*Note:*  It seems that RJB works with Java 6, except when it doesn't, and for a few people it doesn't.  In that case, either switch to Java 1.5, or simply run Buildr on JRuby using Java 6.
-
-
-h2.  Bugs resulting from a dangling comma or period
-
-Ruby statements don't need a delimiter and can span multiple lines, which can lead to bugs resulting from dangling commas and periods left at the end of the line.  For example:
-
-{{{!ruby
-compile.with 'org.apache.axis2:axis2:jar:1.2',
-test.with 'log4j:log4j:jar:1.1'
-}}}
-
-This is actually a single method call with two arguments, separated by a comma. The second argument is the result of calling @test.with@, and makes the test task a pre-requisite of the compile task, leading to a circular dependency.
-
-As you can imagine this happens usually after editing, specifically for commas and periods which are small enough that you won't notice them from a cursory glance at the code, so if all else fails, search for lines that end with one of these characters.
-
-
-h2.  Missing POM breaks transitive dependencies
-
-Occasionally, artifacts are deployed to remote repositories with missing or broken POMs.  Buildr will fail when attempting to resolve transitive dependencies with broken or missing POMs.
-
-In this particular case, failing is doing the right thing.  There's no way for Buildr to tell whether the POM is nowhere to be found, or just a temporary problem accessing the remote server.
-
-If you can determine that the POM file is missing you can work around the problem in three ways.  If you published the artifact, make the release again, getting it to upload the missing files.
-
-If the source repository is not under your control, but you are also using your own repository for the project, you can always create a dummy POM in your own repository.  Buildr will attempt to download the file from either repository, using the first file it finds.
-
-Alternatively, you can make Buildr create a dummy POM file in the local repository, instead of downloading it from a remote repository.  This example creates a dummy POM for Axis JAX-RPC:
-
-{{{!ruby
-artifact 'axis:axis-jaxrpc:pom:1.3' do |task|
-  write task.name, <<-POM
-    <project>
-      <modelVersion>4.0.0</modelVersion>
-      <groupId>axis</groupId>
-      <artifactId>axis-jaxrpc</artifactId>
-      <version>1.4</version>
-    </project>
-  POM
-end
-}}}
-
-
-h2. Buildr fails to run after install with a "stack level too deep (SystemStackError)" error
-
-A particular quirk of an existing Ruby setup can cause problems when running Buildr.  If a system already has several Ruby directories that are in the @PATH@, it is often nice (appropriate?) to have them in @RUBYLIB@ as well (to be able to require them).  If there are several of them a user may decide that @RUBYLIB=$PATH@ is a good way to handle this (or some less automated method that has the same effect).
-
-The culprit is having the Gem's binary directory show up in @RUBYLIB@.  For example, Buildr's @bin/buildr@ includes this line:
-
-{{{!sh
-require 'buildr'
-}}}
-
-Under normal circumstances, this tells RubyGems to load @buildr.rb@ from the Gem's library directory.  When @RUBYLIB@ points to the Gem's @bin@ directory, it ends up loading itself repeatedly. 
-
-To solve this, remove Buildr's @bin@ directory from @RUBYLIB@.  Removing all directories that you don't actually need is better (other Gems may have the same problem).

data/doc/pages/whats_new.textile

@@ -1,323 +0,0 @@
-h1.  What's New
-
-h2.  Buildr 1.3.3
-
-* Support for "JtestR":http://jtestr.codehaus.org/ test framework.
-* Support for "Emma":http://emma.sourceforge.net/ code coverage tool.
-* Growl notifications (OS X only).
-* Starting with this release you can use the @build.yml@ file to control versions of various 3rd party libraries, e.g. Ant, JUnit, ScalaCheck.
-* The _release_ task now supports alternative SVN repository layouts. Releases are tagged in SVN using the version number, but you can customize the tag name (see @Releases.tag_name@). The @NEXT_VERSION@ constant is no longer used during the release process.
-* This release is tested against JRuby 1.1.3 and JRuby 1.1.4. There are also some improvements towards Ruby 1.9 support.
-* 27 other bug fixes and minor changes, see the "CHANGELOG":changelog.html for full details.
-
-
-h2.  Buildr 1.3.2
-
-* New @--prereqs@ command line argument lists all the tasks and their dependencies. You can also filter specific tasks by following with a regular expression, for example, @--prereqs foo@.
-* Upgraded to latest release of Net::SSH, Net::SFTP, RubyForge and RubyGems.
-* Upgraded to JUnit 4.4 and fixed case where abstract classes extending TestCase would lead to tests failing.
-* The target/test/class and /resources directories now come first in the classpath, ahead of any code compiled code and resources copied over from src/main.
-* Fixed: BUILDR-90 Installing from source doesn't work with JRuby.
-* Fixed: BUILDR-91 When doing a release, buildr should spawn the same version of buildr
-* Fixed: BUILDR-92 IDEA 7x: add resources directories to classpath.
-* Fixed: BUILDR-95: Only download Scala test framework artifacts when required
-* Fixed: BUILDR-100 Directory structure documentation needs updating.
-* Fixed: Installation instructions updated for RubyGems 1.2.0.
-
-
-h2.  Buildr 1.3.1
-
-* Fixed to specific Gem dependencies, so should install cleanly on Windows.
-* Buildr now supports publishing files to HTTP server for remote repositories that support HTTP uploads (PUT).
-* Buildr now supports reading files from SFTP server and upgrades to  Net::SSH 2.0 and Net::SFTP 2.0.
-* HTTP downloads now accept URLs with query parameters (Tommy Knowlton).
-* On OS X if you are not using the default JDK, you can set the JAVA_HOME environment variable to point to any other JDK (Nathan Hamblen).
-* JUnit properly passes options[:environment] as environment variables to the test case.  In addition options[:java_args] are now passed as arguments to the JVM, for example to set heap size, only applicable when forking (the default mode when running JUnit).
-* Fixed BUILDR-75: Filter now runs if there's a target directory, even if there are no source files to copy over, and creates an empty target directory.  The previous behavior caused some problems with code that checked if resource.target was nil, but didn't check if there are any resource.sources to process.
-* Added the jibx_bind method to use JiBX for Java<=>XML binding (by David Peterson).
-
-
-h2.  Buildr 1.3
-
-h3.  Multiple Languages
-
-The main focus of this release is supporting multiple languages for compiling and testing.
-
-For each project, Buildr will attempt to infer which compiler to use based on the source files it finds, for example, if it finds @.java@ files in the @src/main/java@ directory, it will switch to the javac compiler, if it finds @.scala@ files in the @src/main/scala@ directory, to the scalac compiler and so forth.
-
-Different compilers may use different target directory, @target/classes@ is picked for JVM compilers (Java, Scala, Groovy, etc), so resources are not copied to their own directory, @target/resources@.  The prepare task has been removed.
-
-Not all languages have classpaths, so @compile.classpath@ is now known as @compile.dependencies@, but the old attribute still exists for backward compatibility.
-
-Also, for consistency, the test target directories have changed to @target/test/classes@ and @target/test/resources@, respectively.
-
-Speaking of tests, you can compile code in one language and use a different language to test it, say, if you're interested in compiling Java code and testing it with Ruby, or compiling Flash and running a Java test suite.
-
-As before, you can pick the test framework by calling @test.using(<framework>)@.  Buildr will attempt to pick one by default, for example, if the tests are written in Java, it will default to JUnit.
-
-And, since not all languages package to JARs, the default packaging is either inferred from the compiler (so @:jar@ when compiling Java code), otherwise to @:zip@.  All this defaulting means that @package()@ with no arguments does the right thing in more cases, and most probably won't break anyone's buildfiles.
-
-I've tried to keep the compiler API as simple as possible, making it easy to add new compilers; however, I had to change the test framework API to accommodate the new features, so old test frameworks will not work on 1.3.
-
-
-h3.  Scala Support
-
-Buildr now supports "Scala":http://www.scala-lang.org/, using both native and  fast Scala compiler.
-
-Read more about "using Scala":languages.html#scala.
-
-
-h3.  Groovy Support
-
-Buildr now supports Groovy, using the Groovyc Ant task.
-
-Read more about "using Groovy":languages.html#groovy.
-
-
-h3.  Packaging Files
-
-The @package@ method is convenient enough that you can now use it to generate artifacts, an in addition to generate regular file tasks, specifying the file name using the @:file@ attribute.  For example:
-
-{{{!ruby
-package :zip, :file=>_('target/interesting.zip')
-}}}
-
-Since this package is not an artifact and does not have a specification, it will not automatically install itself in the local repository or upload to a remote repository.  For these, use the @package@ method as before.
-
-Read more about "the package method":packaging.html#specifying_and_referencing_packages.
-
-
-h3.  Packaging EARs
-
-EAR packages support four component types:
-
-|_. Argument  |_. Component                     |
-| @:war@      | J2EE Web Application (WAR).     |
-| @:ejb@      | Enterprise Java Bean (JAR).     |
-| @:jar@      | J2EE Application Client (JAR).  |
-| @:lib@      | Shared library (JAR).           |
-
-This example shows two ways for adding components built by other projects:
-
-{{{!ruby
-package(:ear) << project('coolWebService').package(:war)
-package(:ear).add project('commonLib') # By default, the JAR package
-}}}
-
-EAR packages include an @application.xml@ file in the @META-INF@ directory that describes the application and its component.  This file is created for you during packaging, by referencing all the components added to the EAR.  There are a couple of things you will typically want to change.
-
-* *display-name* -- The application's display name defaults to the project's identifier.  You can change that by setting the @display_name@ attribute.
-
-* *context-root* -- WAR components specify a context root, based on the package identifier, for example, "cool-web-1.0.war" will have the context root "cool-web".  To specify a different context root, add the WAR package with the @context_root@ option.
-
-"Read more ...":packaging.html#packaging_ears
-
-
-h3.  JRuby Support
-
-We now offer two versions of Buildr, one for Ruby and one for JRuby.  They're exactly the same, except the Ruby version will also install RJB (Ruby Java Bridge), the JRuby version obviously can do well without it.
-
-"Read more ...":download.html#jruby
-
-Buildr provides a "Nailgun":http://www.martiansoftware.com/nailgun/index.html server when running on JRuby. Using the integrated BuildrServer allows for  faster task execution and avoid frequent JVM startup overhead. 
-
-"Read more ...":more_stuff.html#nailgun
-
-
-h3. Behaviour-Driven Development
-
-Given that many languages are now supported by Buildr, the same is true for testing, the convention is to store BDD files under the @src/spec/{lang}@  directory.  The following table shows the framework's name you can use to select them  for your projects. Buildr follows each framework's naming convention.
-
-|_. test.using     |_. Test file name convention                  |
-| @:jbehave@       |  @src/spec/java/**/*Behaviour.java@            |
-| @:rspec@         |  @src/spec/ruby/**/*_spec.rb@                  |
-| @:easyb@         |  @src/spec/groovy/**/*{Story,Behavior}.groovy@ |
-
-"Read more ...":testing.html#bdd
-
-
-h3.  Profiles
-
-Different environments may require different configurations, some you will want to control with code, others you will want to specify in the profiles file.
-
-The profiles file is a YAML file called @profiles.yaml@ that you place in the same directory as the Buildfile.  We selected YAML because it's easier to read and edit than XML.
-
-For example, to support three different database configurations, we could write:
-
-{{{!yaml
-# HSQL, don't bother storing to disk.
-development:
-  db: hsql
-  jdbc: hsqldb:mem:devdb
-
-# Make sure we're not messing with bigstrong.
-test:
-  db: oracle
-  jdbc: oracle:thin:@localhost:1521:test
-
-# The real deal.
-production:
-  db: oracle
-  jdbc: oracle:thin:@bigstrong:1521:mighty
-}}}
-
-You can also use profiles to specify default filters for the "@resources@ task":building.html#resources.
-
-"Read more ...":settings_profiles.html#profiles
-
-
-h3.  Settings and build YAML files
-
-In addition to profiles, we also allow you to specify personal and build settings using two YAML files.
-
-Personal settings are placed in the @.buildr/settings.yaml@ file under your home directory. Settings stored there will be applied the same across all builds.
-
-For example:
-
-{{{!yaml
-# The repositories hash is read automatically by buildr.
-repositories:
-
-  # customize user local maven2 repository location
-  local: some/path/to/my_repo
-
-  relase_to:
-    url: http://intra.net/maven2
-    username: john
-    password: secret
-
-# You can place settings of your own, and reference them 
-# on buildfiles. 
-im:
-  server: jabber.company.com
-  usr: notifier@company-jabber.com
-  pwd: secret
-}}}
-
-"Read more ...":settings_profiles.html#personal_settings
-
-Build settings are placed in the @build.yaml@ file located in the same directory that the @buildfile@. Normally this file would be managed by the project revision control system, so settings here are shared between developers.
-
-For example:
-
-{{{!yaml
-# This project requires the following ruby gems, buildr addons
-gems: 
-  # Suppose we want to notify developers when testcases fail.
-  - buildr-twitter-notifier-addon >=1
-  # we test with ruby mock objects
-  - mocha
-  - ci_reporter
-
-# The artifact declarations will be automatically loaded by buildr, so that
-# you can reference artifacts by name (a ruby-symbol) on your buildfile.
-artifacts:
-  spring: org.springframework:spring:jar:2.0
-  log4j: log4j:log4j:jar:1.0
-  j2ee: geronimo-spec:geronimo-spec:j2ee:jar:1.4-rc4
-
-# Of course project settings can be defined here
-jira: 
-  uri: https://jira.corp.org
-}}}
-
-"Read more ...":settings_profiles.html#build_settings
-
-
-h3.  Using Gems for extensions and 3rd party libraries
-
-"RubyGems":http://rubygems.rubyforge.org provides the @gem@ command line tool that you can use to search, install, upgrade, package and distribute gems. It installs all gems into a local repository that is shared across your builds and all other Ruby applications you may have running.  You can install a gem from a local file, or download and install it from any number of remote repositories.
-
-If your build depends on other gems, you will want to specify these dependencies as part of your build and check that configuration into source control.  That way you can have a specific environment that will guarantee repeatable builds, whether you're building a particular version, moving between branches, or joining an existing project.  Buildr will take care of installing all the necessary dependencies, which you can then manage with the @gem@ command.
-
-Use the @build.yaml@ file to specify these dependencies (see "Build Settings":settings_profiles.html#build_settings for more information), for example:
-
-{{{!yaml
-# This project requires the following gems
-gems: 
-  # Suppose we want to notify developers when testcases fail.
-  - buildr-twitter-notifier-addon >=1
-  # we test with ruby mock objects
-  - mocha
-  - ci_reporter
-}}}
-
-"Read more ...":more_stuff.html#using_gems
-
-
-h3.  New API for accessing Java libraries
-
-Java classes are accessed as static methods on the @Java@ module, for example:
-
-{{{!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)
-}}}
-
-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.
-
-For example, Ant is loaded as follows:
-
-{{{!ruby
-Java.classpath << 'org.apache.ant:ant:jar:1.7.0'
-}}}
-
-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.
-
-"Read more ...":more_stuff.html#using_java_libraries
-
-
-h3.  Creating Extensions
-
-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
-class Project
-  include MyExtension
-end
-}}}
-
-You can also extend a given project instance and only that instance by extending it with the module:
-
-{{{!ruby
-define 'foo' do
-  extend MyExtension
-end
-}}}
-
-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.
-
-"Read more ...":extending.html#creating_extensions
-
-
-h3.  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.
-
-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.
-
-"Read more ...":extending.html#using_alternative_layouts
-
-
-h3.  Other
-
-* Buildr 1.3 upgrades to Rake 0.8, RSpec 1.1, RJB 1.1 and OpenJPA 1.0.1.  Buildr no longer includes or uses Facets.
-* JUnit tests now operate on all compiled test classes that extend @junit.framework.TestCase@ or use the @Test@ annotation; TestNG test cases are filtered by annotation.  Test cases no longer have to use a specific file name.
-* Remote repositories now support HTTP Basic Authentication.
-* The prepare task has been removed, if you need to, simply add a prerequisite to the compile task.
-
-
-h3.  Documentation
-
-* The "What's new?":whats_new.html page (this one, actually), summarizes all the important new features and changes in each release.
-* The "Recipes":recipes.html page (also available in the PDF) lists recipes for using Buildr, collected from the mailing list.  Feel free to contribute tips, tricks and techniques.
-* The "Troubleshooting":troubleshooting.html page (also available in the PDF) collects troubleshooting ideas from the mailing list.
-* The "Getting Started":getting_started.html has been rewritten to cover all you need to know about downloading and installing Buildr on Linux, OS X, Windows and with JRuby (1.1 or later).
-* A new "Contributing":contributing.html page has more details on how to file bugs, policy for submitting patches, running Buildr test cases, and helping with the documentation.
-* A new page for "Settings and Profiles":settings_profiles.html.
-* The "Extending Buildr":extending.html page that deals with writing your own tasks, creating extensions and specifying alternative layouts.
-* The site also includes "RSpec report":specs.html which provides the official specification against which we test each release.