buildr 1.3.4-java → 1.3.5-java

data/CHANGELOG

@@ -1,3 +1,37 @@
+1.3.5 (2009-10-05)
+* Added:  Interactive shell (REPL) support
+* Added:  BeanShell as default shell for java projects, bsh is small and it's
+          syntax provides the closest to an interpreted java. The BeanShell
+          console includes a graphical class browser. Shell is named :bsh
+* Added:  Mandriva (urpmi) installation support (with help from Franck Villaume).
+* Added:  BUILDR-56 Download Scala artifacts if not available locally
+* Added:  BUILDR-163 cobertura:check (Marko Sibakov, Daniel Spiewak).
+* Added:  BUILDR-295 Eclipse task: make 'M2_REPO' repository variable configurable
+* Added:  BUILDR-300 Make Eclipse task more configurable (Antoine Toulme, Alex Boisvert)
+* Change: Upgraded to rubyforge-1.0.5 and net-ssh 2.0.15
+* Change: Monkey-Patched FileUtils::sh on JRuby to use POSIX `system`
+* Change: Updated to Rake 0.8.7, RSpec 1.2.8 and JRuby-openssl 0.5.2.
+* Change: Updated to easyb 0.9 (Joel Muzzerall)
+* Change: Updated to TestNG 5.10
+* Change: Updated to JRuby 1.3.1
+* Fixed:  BUILDR-23 Support for setting file mode when packaging (Ittay Dror).
+* Fixed:  BUILDR-278 tasks/*.rake files are loaded after the buildfile (Rhett Sutphin)
+* Fixed:  BUILDR-282 release goal should not strip leading '0' digits from version numbers.
+* Fixed:  BUILDR-289 Improved error message when JAVA_HOME points to an invalid JRE/JDK installation
+* Fixed:  BUILDR-290 Dependencies cannot be downloaded over SSL.
+* Fixed:  BUILDR-291 Local tasks do not support arguments (Ittay Dror).
+* Fixed:  BUILDR-292 Workaround for JRUBY-3381 on FileUtils.mv
+* Fixed:  BUILDR-301 TestNG doesn't report failure if more than one test fails
+* Fixed:  BUILDR-307 Failures are not reported correctly for ScalaTest (Jeremie Lenfant-Engelmann)
+* Fixed:  BUILDR-313 Prevent release with uncommitted_files on Git 1.4.3+ (Alexis Midon)
+* Fixed:  BUILDR-315 Fix Eclipse .classpath for local libraries (Mat Schaffer)
+* Fixed:  BUILDR-304 Referencing an existing package task using the package
+          method fails if the package has a custom filename (Rhett Sutphin)
+* Fixed:  BUILDR-322 When specifying files (instead of directories) as sources for compile task, 
+          Buildr uses target directory timestamp only (not compiled output timestamp)
+* Fixed:  BUILDR-324: Regression - baseDir system property is not set when executing tests [Alexis Midon]
+* Fixed:  BUILDR-325: Overriding package spec with classifer doesn't work (Antoine Toulme)
+
 1.3.4 (2009-04-21)
 * Added:  BUILDR-93 Add specs for ScalaCheck integration
 * Added:  BUILDR-94 Add specs for Scala Specs integration
@@ -32,6 +66,7 @@
 * Change: Buildr now uses Jekyll to generate Web site/documentation:
 http://github.com/mojombo/jekyll/ This replaces Docter so less code to
 maintain and the same Textile/Liquid mechanism as when using Github pages.
+* Change: To access Release object (e.g. to set tag_name) use Release.find.
 * Fixed:  Removed double complete/fail messages showing up on console.
 * Fixed:  BUILDR-140 Get rid of const_defined? all across the board.
 * Fixed:  BUILDR-158 Nailgun is now a delegate for buildr/drb (a pure-ruby dRuby server)

data/README.rdoc

@@ -27,7 +27,7 @@ http://buildr.apache.org/
 
 === RTFM
 
-* Buildr documentation: http://buildr.apache.org/
+* Buildr documentation: http://buildr.apache.org
 * More about Rake: http://docs.rubyrake.org
 * Antwrap documentation: http://antwrap.rubyforge.org
 

data/Rakefile

@@ -28,9 +28,9 @@ end
 
 # Load the Gem specification for the current platform (Ruby or JRuby).
 def spec(platform = RUBY_PLATFORM[/java/] || 'ruby')
-  @specs ||= ['ruby', 'java'].inject({}) { |hash, platform|
-    $platform = platform
-    hash.update(platform=>Gem::Specification.load('buildr.gemspec'))
+  @specs ||= ['ruby', 'java', 'x86-mswin32'].inject({}) { |hash, spec_platform|
+    $platform = spec_platform
+    hash.update(spec_platform=>Gem::Specification.load('buildr.gemspec'))
   }
   @specs[platform]
 end

data/buildr.buildfile

@@ -16,6 +16,7 @@
 $LOADED_FEATURES << 'jruby' unless RUBY_PLATFORM =~ /java/ # Pretend to have JRuby, keeps Nailgun happy.
 require 'buildr/jetty'
 require 'buildr/nailgun'
+require 'buildr/scala'
 repositories.remote << 'http://repo1.maven.org/maven2'
 repositories.remote << 'http://scala-tools.org/repo-releases/'
 
@@ -23,10 +24,14 @@ repositories.remote << 'http://scala-tools.org/repo-releases/'
 define 'buildr' do
   compile.using :source=>'1.4', :target=>'1.4', :debug=>false
 
-  define 'java' do  
+  define 'java' do
     compile.using(:javac).from(FileList['lib/buildr/java/**/*.java']).into('lib/buildr/java')
   end
 
+  define 'scala' do
+    compile.using(:scalac).from(FileList['lib/buildr/scala/**/*.scala']).into('lib/buildr/scala')
+  end
+
   desc 'Buildr extra packages (Antlr, Cobertura, Hibernate, Javacc, JDepend, Jetty, OpenJPA, XmlBeans)'
   define 'extra', :version=>'1.0' do
     compile.using(:javac).from(FileList['addon/buildr/**/*.java']).into('addon/buildr').with(Buildr::Jetty::REQUIRES, Buildr::Nailgun::ARTIFACT_SPEC)

data/buildr.gemspec

@@ -16,7 +16,7 @@
 
 Gem::Specification.new do |spec|
   spec.name           = 'buildr'
-  spec.version        = '1.3.4'
+  spec.version        = '1.3.5'
   spec.author         = 'Apache Buildr'
   spec.email          = "users@buildr.apache.org"
   spec.homepage       = "http://buildr.apache.org/"
@@ -47,18 +47,19 @@ for those one-off tasks, with a language that's a joy to use.
   spec.post_install_message = "To get started run buildr --help"
 
   # Tested against these dependencies.
-  spec.add_dependency 'rake',                 '0.8.4'
+  spec.add_dependency 'rake',                 '0.8.7'
   spec.add_dependency 'builder',              '2.1.2'
-  spec.add_dependency 'net-ssh',              '2.0.11'
+  spec.add_dependency 'net-ssh',              '2.0.15'
   spec.add_dependency 'net-sftp',             '2.0.2'
   spec.add_dependency 'rubyzip',              '0.9.1'
-  spec.add_dependency 'highline',             '1.5.0'
-  spec.add_dependency 'rubyforge',            '1.0.3'
-  spec.add_dependency 'hoe',                  '1.11.0'
-  spec.add_dependency 'rjb',                  '1.1.6' if spec.platform.to_s == 'ruby' 
+  spec.add_dependency 'highline',             '1.5.1'
+  spec.add_dependency 'rubyforge',            '1.0.5'
+  spec.add_dependency 'hoe',                  '2.3.3'
+  spec.add_dependency 'rjb',                  '1.1.9' if spec.platform.to_s == 'ruby'
+  spec.add_dependency 'rjb',                  '1.1.6' if spec.platform.to_s == 'x86-mswin32'
   spec.add_dependency 'Antwrap',              '0.7.0'
-  spec.add_dependency 'rspec',                '1.2.2'
+  spec.add_dependency 'rspec',                '1.2.8'
   spec.add_dependency 'xml-simple',           '1.0.12'
   spec.add_dependency 'archive-tar-minitar',  '0.5.2'
-  spec.add_dependency 'jruby-openssl',        '0.3'   if spec.platform.to_s == 'java'
+  spec.add_dependency 'jruby-openssl',        '0.5.2' if spec.platform.to_s == 'java'
 end

data/doc/_config.yml

@@ -0,0 +1 @@
+pygments: true

data/doc/_layouts/default.html

@@ -1,6 +1,6 @@
 <html>
   <head>
-    <meta content='text/html;charset=UTF-8' http-equiv='Content-Type' />
+    <meta content='text/html;charset=UTF-8' http-equiv='Content-Type'>
     <title>buildr &mdash; {{ page.title }}</title>
     <style type='text/css'>
       @import 'css/default.css';
@@ -9,30 +9,28 @@
     <style media='print' type='text/css'>
       @import 'css/print.css';
     </style>
-    <meta content='Official Buildr documentation from the people in the know' name='subject' />
-    <link href='images/favicon.png' rel='shortcut icon' />
+    <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>
+        <a href='http://buildr.apache.org/' title="The build system that doesn't suck"><img alt='buildr' src='images/buildr.png'></a>
+        <div class='tagline'>The build system that doesn't suck</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='quick_start.html'>Quick Start</a></li>
+              <li><a href='installing.html'>Installing & Running</a></li>
               <li><a href='http://cwiki.apache.org/confluence/display/BUILDR/Index'>Community Wiki</a></li>
             </ol>
           </li>
           <li>Using Buildr
             <ol class="toc">
-              <li><a href='getting_started.html'>Getting Started</a></li>
+              <li><a href='buildr.pdf'>This Guide (PDF)</a></li>
               <li><a href='projects.html'>Projects</a></li>
               <li><a href='building.html'>Building</a></li>
               <li><a href='artifacts.html'>Artifacts</a></li>
@@ -46,7 +44,7 @@
             </ol>
           </li>
           <li>Reference
-            <ol  class="toc">
+            <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>
@@ -54,7 +52,8 @@
             </ol>
           </li>
           <li>Get Involved
-            <ol  class="toc">
+            <ol class="toc">
+              <li><a href='download.html'>Download</a></li>
               <li><a href='mailing_lists.html'>Mailing Lists</a></li>
               <li><a href='http://issues.apache.org/jira/browse/Buildr'>Issues/Bugs</a></li>
               <li><a href='contributing.html'>Contributing</a></li>
@@ -62,14 +61,21 @@
               <li><a href='coverage/index.html'>Coverage</a></li>
             </ol>
           </li>
+          <li>
+            <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>
+          </li>
+          <li>The Buildr Book
+            <p><a href='http://www.amazon.com/Buildr/dp/1442160942/'><img src='images/1442160941-frontcover.jpg' style='width:120px'></a></p>
+            <p>Based on the Buildr documentation, available from <a href='http://www.amazon.com/Buildr/dp/1442160942/'>Amazon</a> and
+            <a href='http://www.createspace.com/3382199'>CreateSpace</a></p>
+          </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 id='{{ page.title | downcase | replace(' ', '_') }}'>{{ page.title }}</h1>

data/doc/artifacts.textile

@@ -10,12 +10,10 @@ Artifacts. We designed Buildr to work as a drop-in replacement for Maven 2.0, an
 
 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:
 
-<notextile>
 {% highlight text %}
 group:id:type:version
 group:id:type:classifier:version
 {% endhighlight %}
-</notextile>
 
 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.
 
@@ -26,40 +24,33 @@ If your Buildfile spells out @'org.apache.axis2:axis2:jar:1.2'@ more than once,
 
 You can use Ruby's syntax to do simple string substitution, for example:
 
-<notextile>
 {% highlight ruby %}
 AXIS_VERSION = '1.2'
 
 compile.with "org.apache.axis2:axis2:jar:#{AXIS_VERSION}"
 {% endhighlight %}
-</notextile>
 
 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:
 
-<notextile>
 {% highlight ruby %}
 AXIS2 = 'org.apache.axis2:axis2:jar:1.2'
 
 compile.with AXIS2
 {% endhighlight %}
-</notextile>
 
 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:
 
-<notextile>
 {% highlight ruby %}
 AXIOM  = group('axiom-api', 'axiom-impl', 'axiom-dom',
   :under=>'org.apache.ws.commons.axiom', :version=>'1.2.4')
 {% endhighlight %}
-</notextile>
 
 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:
 
-<notextile>
 {% highlight ruby %}
 OPENJPA = ['org.apache.openjpa:openjpa-all:jar:0.9.7',
   'net.sourceforge.serp:serp:jar:1.12.0']
@@ -67,11 +58,9 @@ AXIS_OF_WS = [AXIS2, AXIOM]
 
 compile.with OPENJPA, AXIS_OF_WS
 {% endhighlight %}
-</notextile>
 
 Another way to group related artifacts together and access them individually is using the @struct@ shortcut.  For example:
 
-<notextile>
 {% highlight ruby %}
 JAVAX = struct(
   :activation  =>'javax.activation:activation:jar:1.1',
@@ -81,23 +70,19 @@ JAVAX = struct(
 
 compile.with JAVAX.persistence, OPENJPA
 {% endhighlight %}
-</notextile>
 
 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:
 
-<notextile>
 {% highlight ruby %}
 require '../shared/artifacts'
 {% endhighlight %}
-</notextile>
 
 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:
 
-<notextile>
 {% highlight ruby %}
 AXIS = { :group=>'org.apache.axis2', :id=>'axis2', :version=>'1.2' }
 compile.with AXIS
@@ -105,7 +90,6 @@ puts compile.dependencies.first.to_hash
 => { :group=>'org.apache.axis2', :id=>'axis2',
      :version=>'1.2', :type=>:jar }
 {% endhighlight %}
-</notextile>
 
 
 h2(#repositories). Specifying Repositories
@@ -114,62 +98,50 @@ Buildr can download artifacts for you, but only if you tell it where to find the
 
 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:
 
-<notextile>
 {% highlight ruby %}
 repositories.remote << 'http://www.ibiblio.org/maven2/'
 {% endhighlight %}
-</notextile>
 
 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 (use @HTTPS_PROXY@ for proxying HTTPS connections).  You can also work without a proxy for certain hosts by specifying the @NO_PROXY@ environment variable.  For example:
 
-<notextile>
 {% highlight sh %}
 $ export HTTP_PROXY = 'http://myproxy:8080'
 $ export NO_PROXY = '*.mycompany.com,localhost,special:800'
 {% endhighlight %}
-</notextile>
 
 Alternatively you can use the Buildr options @proxy.http@ and @proxy.exclude@:
 
-<notextile>
 {% highlight ruby %}
 options.proxy.http = 'http://myproxy:8080'
 options.proxy.exclude << '*.mycompany.com'
 options.proxy.exclude << 'localhost'
 {% endhighlight %}
-</notextile>
 
 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:
 
-<notextile>
 {% highlight ruby %}
 repositories.local = '/usr/local/maven/repository'
 {% endhighlight %}
-</notextile>
 
 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:
 
-<notextile>
 {% highlight sh %}
 $ buildr artifacts
 {% endhighlight %}
-</notextile>
 
 
 h2(#downloading). Downloading Artifacts
 
 Within your buildfile you can download artifacts directly by invoking them, for example:
 
-<notextile>
 {% highlight ruby %}
 artifact('org.apache.openjpa:openjpa-all:jar:0.9.7').invoke
 artifacts(OPENJPA).each(&:invoke)
 {% endhighlight %}
-</notextile>
 
 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@.
 
@@ -179,14 +151,12 @@ But there are exceptions to the rule.  Say we want to download the Dojo widget l
 
 We can still treat Dojo as an artifact, by telling Buildr where to download it from:
 
-<notextile>
 {% 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 %}
-</notextile>
 
 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.
 
@@ -211,22 +181,18 @@ Some artifacts do not fall into either category.  In this example we're going to
 
 So let's start by creating a task that downloads the ZIP, and another one to extract it and create the JAR file:
 
-<notextile>
 {% highlight ruby %}
 app_zip = download('target/app.zip'=>url)
 bean_jar = file('target/app/bean.jar'=>unzip('target/app'=>app_zip))
 {% endhighlight %}
-</notextile>
 
 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:
 
-<notextile>
 {% highlight ruby %}
 bean = artifact('example.com:beans:jar:1.0').from(bean_jar)
 {% endhighlight %}
-</notextile>
 
 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.
 
@@ -234,12 +200,10 @@ Use the @install@ method if you want the artifact and its POM installed in the l
 
 Our example ends by including the artifact in the @install@ and @upload@ tasks:
 
-<notextile>
 {% highlight ruby %}
 install bean
 upload bean
 {% endhighlight %}
-</notextile>
 
 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@.
 

data/doc/building.textile

@@ -31,12 +31,10 @@ When you pass an artifact specification to @compile.with@, it creates an @Artifa
 
 For now let's just show a simple example:
 
-<notextile>
 {% 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 %}
-</notextile>
 
 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.html.
 
@@ -44,22 +42,18 @@ Likewise, the @compile@ task has an array of file tasks that point at the source
 
 For example, let's run the APT tool on our annotated source code before compiling it:
 
-<notextile>
 {% highlight ruby %}
 compile.from apt
 {% endhighlight %}
-</notextile>
 
 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:
 
-<notextile>
 {% highlight ruby %}
 jjtree = jjtree(_('src/main/jjtree'), :in_package=>'com.acme')
 compile.from javacc(jjtree, :in_package=>'com.acme'), jjtree
 {% endhighlight %}
-</notextile>
 
 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.
 
@@ -71,12 +65,10 @@ We use method pairs to give you finer control over the compiler, but also a way
 
 For example:
 
-<notextile>
 {% highlight ruby %}
 compile.from('srcs').with('org.apache.axis2:axis2:jar:1.2').
   into('classes').using(:target=>'1.4')
 {% endhighlight %}
-</notextile>
 
 Buildr uses the method pair and method chaining idiom in many places to make your life easier without sacrificing flexibility.
 
@@ -84,28 +76,22 @@ Occasionally, you'll need to post-process the generated bytecode.  Since you onl
 
 For example, to run the OpenJPA bytecode enhancer after compiling the source files:
 
-<notextile>
 {% highlight ruby %}
 compile { open_jpa_enhance }
 {% endhighlight %}
-</notextile>
 
 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:
 
-<notextile>
 {% highlight ruby %}
 compile.options.target = '1.5'
 compile.options.lint = 'all'
 {% endhighlight %}
-</notextile>
 
 Or, if you want to chain methods together:
 
-<notextile>
 {% highlight ruby %}
 compile.using :target=>'1.5', :lint=>'all'
 {% endhighlight %}
-</notextile>
 
 
 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.
@@ -114,7 +100,6 @@ The options available to you depend on which compiler you are using for this par
 
 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:
 
-<notextile>
 {% highlight ruby %}
 # When calling buildr
 $ buildr compile debug=off
@@ -123,7 +108,6 @@ $ buildr compile debug=off
 $ export DEBUG=off
 $ buildr compile
 {% endhighlight %}
-</notextile>
 
 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.
 
@@ -135,16 +119,13 @@ The @compile@ task comes bundled with a @resources@ task.  It copies files from
 
 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" :
 
-<notextile>
 {% highlight ruby %}
 resources.filter.using 'version'=>version,
   'copyright'=>'Acme Inc (C) 2007'
 {% endhighlight %}
-</notextile>
 
 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:
 
-<notextile>
 {% highlight yaml %}
 filter: &alpha1
   version: experimental
@@ -155,7 +136,6 @@ development:
 test:
   filter: *alpha1
 {% endhighlight %}
-</notextile>
 
 You can specify a different format by passing it as the first argument. Supported formats include:
 
@@ -167,38 +147,30 @@ You can specify a different format by passing it as the first argument. Supporte
 
 For example, using the @:ruby@ format instead of the default @:maven@ format:
 
-<notextile>
 {% highlight ruby %}
 resources.filter.using :ruby, 'version'=>version,
   'copyright'=>'Acme Inc (C) 2007'
 {% endhighlight %}
-</notextile>
 
 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:
 
-<notextile>
 {% highlight ruby %}
 resources.from _('src/etc')
 {% endhighlight %}
-</notextile>
 
 You can select to copy only specific files using common file matching patterns. For example, to include only HTML files:
 
-<notextile>
 {% highlight ruby %}
 resources.include '*.html'
 {% endhighlight %}
-</notextile>
 
 To include all files, except for files in the @scratch@ directory:
 
-<notextile>
 {% highlight ruby %}
 resources.exclude 'scratch/*'
 {% endhighlight %}
-</notextile>
 
 The filter always excludes the @CVS@ and @.svn@ directories, and all files ending with @.bak@ or @~@, so no need to worry about these.
 
@@ -208,12 +180,10 @@ You can use filters elsewhere.  The @filter@ method creates a filter, the @into@
 
 For example:
 
-<notextile>
 {% highlight ruby %}
 filter('src/specs').into('target/specs').
   using('version'=>version, 'created'=>Time.now).run
 {% endhighlight %}
-</notextile>
 
 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.
 
@@ -226,24 +196,20 @@ You can extend the @build@ task in two ways.  You can add more prerequisites tha
 
 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:
 
-<notextile>
 {% highlight ruby %}
 db = Derby.create(_('target/derby/db')=>_('src/main/sql/derby.sql'))
 package(:zip).include db
 {% endhighlight %}
-</notextile>
 
 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:
 
-<notextile>
 {% highlight ruby %}
 db = Derby.create(_('target/derby/db')=>_('src/main/sql/derby.sql'))
 build db
 package(:zip).include db
 {% endhighlight %}
-</notextile>
 
 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.
 
@@ -251,14 +217,12 @@ p(tip). @Derby.create@ is not part of Buildr, you can get "derby.rake":http://sv
 
 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:
 
-<notextile>
 {% highlight ruby %}
 build do
   filter('src/specs').into('target/specs').
     using('version'=>version, 'created'=>Time.now).run
 end
 {% endhighlight %}
-</notextile>
 
 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.
 
@@ -271,11 +235,9 @@ It basically erases the target directories, the one called @target@, and if you
 
 For example: 
 
-<notextile>
 {% highlight ruby %}
 clean { rm_rf _('staged') }
 {% endhighlight %}
-</notextile>
 
 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.