svn commit: r752665 [2/2] - in /buildr/trunk: doc/ doc/_layouts/ doc/css/ doc/pages/ rakelib/

[as...@apache.org]

Copied: buildr/trunk/doc/packaging.textile (from r752580, buildr/trunk/doc/pages/packaging.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/packaging.textile?p2=buildr/trunk/doc/packaging.textile&p1=buildr/trunk/doc/pages/packaging.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/packaging.textile (original)
+++ buildr/trunk/doc/packaging.textile Wed Mar 11 22:39:02 2009
@@ -1,38 +1,41 @@
-h1. Packaging
+---
+layout: default
+title: Packaging
+---
 
 For our next trick, we're going to try and create an artifact ourselves.  We're going to start with:
 
-{{{!ruby
+{% highlight ruby %}
 package :jar
-}}}
+{% endhighlight %}
 
 We just told the project to create a JAR file in the @target@ directory, including all the classes (and resources) that we previously compiled into @target/classes@.  Or we can create a WAR file:
 
-{{{!ruby
+{% highlight ruby %}
 package :war
-}}}
+{% endhighlight %}
 
 The easy case is always easy, but sometimes we have more complicated use cases which we'll address through the rest of this section.
 
 Now let's run the build, test cases and create these packages:
 
-{{{!sh
+{% highlight sh %}
 $ buildr package
-}}}
+{% endhighlight %}
 
 The @package@ task runs the @build@ task (remember: @compile@ and @test@) and then runs each of the packaging tasks, creating packages in the projects' target directories.
 
 p(tip). The @package@ task and @package@ methods are related, but that relation is different from other task/method pairs.  The @package@ method creates a file task that points to the package in the @target@ directory and knows how to create it.  It then adds itself as a prerequisite to the @package@ task. Translation: you can create multiple packages from the same project.
 
 
-h2. Specifying And Referencing Packages
+h2(#referencing). Specifying And Referencing Packages
 
 Buildr supports several packaging types, and so when dealing with packages, you have to indicate the desired package type.  The packaging type can be the first argument, or the value of the @:type@ argument.  The following two are equivalent:
 
-{{{!ruby
+{% highlight ruby %}
 package :jar
 package :type=>:jar
-}}}
+{% endhighlight %}
 
 If you do not specify a package type, Buildr will attempt to infer one.
 
@@ -40,9 +43,9 @@
 
 To package a particular file, use the @:file@ argument, for example:
 
-{{{!ruby
+{% highlight ruby %}
 package :zip, :file=>_('target/interesting.zip')
-}}}
+{% endhighlight %}
 
 This returns a file task that will run as part of the project's @package@ task (generating all packages).  It will invoke the @build@ task to generate any necessary prerequisites, before creating the specified file.
 
@@ -52,7 +55,7 @@
 
 The artifact specification is based on the project name (using dashes instead of colons), group identifier and version number, all three obtained from the project definition.  You can specify different values using the @:id@, @:group@, @:version@ and @:classifier@ arguments.  For example:
 
-{{{!ruby
+{% highlight ruby %}
 define 'killer-app', :version=>'1.0' do
   # Generates silly-1.0.jar
   package :jar, :id=>'silly'
@@ -67,7 +70,7 @@
     package :zip, :classifier=>'sources'
   end
 end
-}}}
+{% endhighlight %}
 
 The file name is determined from the identifier, version number, classifier and extension associated with that packaging type.
 
@@ -77,45 +80,47 @@
 
 You can use the @packages@ method to obtain a list of all packages defined in the project, for example:
 
-{{{!ruby
+{% highlight ruby %}
 project('killer-app:teh-impl').packages.first
 project('killer-app:teh-impl').packages.select { |pkg| pkg.type == :zip }
-}}}
+{% endhighlight %}
+<!-- -->
 
 
-h2. Packaging ZIPs
+h2(#zip). Packaging ZIPs
 
 ZIP is the most common form of packaging, used by default when no other packaging type applies.  It also forms the basis for many other packaging types (e.g. JAR and WAR).  Most of what you'll find here applies to other packaging types.
 
 Let's start by including additional files in the ZIP package.  We're going to include the @target/docs@ directory and @README@ file:
 
-{{{!ruby
+{% highlight ruby %}
 package(:zip).include _('target/docs'), 'README'
-}}}
+{% endhighlight %}
 
 The @include@ method accepts files, directories and file tasks.  You can also use file pattern to match multiple files and directories.  File patterns include asterisk (@*@) to match any file name or part of a file name, double asterisk (@**@) to match directories recursively, question mark (@?@) to match any character, square braces (@[]@) to match a set of characters, and curly braces (@{}@) to match one of several names.
 
 And the same way you @include@, you can also @exclude@ specific files you don't want showing up in the ZIP.  For example, to exclude @.draft@ and @.raw@ files:
 
-{{{!ruby
+{% highlight ruby %}
 package(:zip).include('target/docs').
   exclude('target/docs/**/*.{draft,raw}')
-}}}
+{% endhighlight %}
 
 So far we've included files under the root of the ZIP.  Let's include some files under a given path using the @:path@ option:
 
-{{{!ruby
+{% highlight ruby %}
 package(:zip).include 'target/docs', :path=>"#{id}-#{version}"
-}}}
+{% endhighlight %}
 
 If you need to use the @:path@ option repeatedly, consider using the @tap@ method instead.  For example:
 
-{{{!ruby
+{% highlight ruby %}
 package(:zip).path("#{id}-#{version}").tap do |path|
   path.include 'target/docs'
   path.include 'README'
 end
-}}}
+{% endhighlight %}
+<!-- -->
 
 p(tip). The @tap@ method is not part of the core library, but a very useful extension.  It takes an object, yields to the block with that object, and then returns that object.
 
@@ -123,16 +128,16 @@
 
 If you need to include a file or directory under a different name, use the @:as@ option.  For example:
 
-{{{!ruby
+{% highlight ruby %}
 package(:zip).include('corporate-logo-350x240.png', :as=>'logo.png')
-}}}
+{% endhighlight %}
 
 You can also use @:as=>'.'@ to include all files from the given directory.  For example:
 
-{{{!ruby
+{% highlight ruby %}
 package(:zip).include 'target/docs/*'
 package(:zip).include 'target/docs', :as=>'.'
-}}}
+{% endhighlight %}
 
 These two are almost identical.  They both include all the files from the @target/docs@ directory, but not the directory itself.  But they operate differently.  The first line expands to include all the files in @target/docs@. If you don't already have files in @target/docs@, well, then it won't do anything interesting.  Your ZIP will come up empty.  The second file includes the directory itself, but strips the path during inclusion.  You can define it now, create these files later, and then ZIP them all up.
 
@@ -142,33 +147,34 @@
 
 You can also merge two ZIP files together, expanding the content of one ZIP into the other.  For example:
 
-{{{!ruby
+{% highlight ruby %}
 package(:zip).merge 'part1.zip', 'part2.zip'
-}}}
+{% endhighlight %}
 
 If you need to be more selective, you can apply the include/exclude pattern to the expanded ZIP.  For example:
 
-{{{!ruby
+{% highlight ruby %}
 # Everything but the libs
 package(:zip).merge('bigbad.war').exclude('libs/**/*')
-}}}
+{% endhighlight %}
+<!-- -->
 
 
-h2. Packaging JARs
+h2(#jar). Packaging JARs
 
 JAR packages extend ZIP packages with support for Manifest files and the META-INF directory.  They also default to include the class files found in the @target/classes@ directory.
 
 You can tell the JAR package to include a particular Manifest file:
 
-{{{!ruby
+{% highlight ruby %}
 package(:jar).with :manifest=>_('src/main/MANIFEST.MF')
-}}}
+{% endhighlight %}
 
 Or generate a manifest from a hash:
 
-{{{!ruby
+{% highlight ruby %}
 package(:jar).with :manifest=>{ 'Copyright'=>'Acme Inc (C) 2007' }
-}}}
+{% endhighlight %}
 
 You can also generate a JAR with no manifest with the value @false@, create a manifest with several sections using an array of hashes, or create it from a proc.
 
@@ -176,32 +182,33 @@
 
 For example, we can get the same result by specifying this at the top project:
 
-{{{!ruby
+{% highlight ruby %}
 manifest['Copyright'] = 'Acme Inc (C) 2007'
-}}}
+{% endhighlight %}
 
 If you need to mix-in the project's manifest with values that only one package uses, you can do so easily:
 
-{{{!ruby
+{% highlight ruby %}
 package(:jar).with :manifest=>manifest.merge('Main-Class'=>'com.acme.Main')
-}}}
+{% endhighlight %}
 
 If you need to include more files in the @META-INF@ directory, you can use the @:meta_inf@ option.  You can give it a file, or array of files.  And yes, there is a @meta_inf@ project property you can set once to include the same set of file in all the JARs.  It works like this:
 
-{{{!ruby
+{% highlight ruby %}
 meta_inf << file('DISCLAIMER') << file('NOTICE')
-}}}
+{% endhighlight %}
 
 If you have a @LICENSE@ file, it's already included in the @meta_inf@ list of files.
 
 Other than that, @package :jar@ includes the contents of the compiler's target directory and resources, which most often is exactly what you intend it to do. If you want to include other files in the JAR, instead or in addition, you can do so using the @include@ and @exclude@ methods.  If you do not want the target directory included in your JAR, simply call the @clean@ method on it:
 
-{{{!ruby
+{% highlight ruby %}
 package(:jar).clean.include( only_these_files )
-}}}
+{% endhighlight %}
+<!-- -->
 
 
-h2. Packaging WARs
+h2(#war). Packaging WARs
 
 Pretty much everything you know about JARs works the same way for WARs, so let's just look at the differences.
 
@@ -209,21 +216,21 @@
 
 Again, you can use the @include@ and @exclude@ methods to change the contents of the WAR.  There are two convenience options you can use to make the more common changes.  If you need to include a classes directory other than the default:
 
-{{{!ruby
+{% highlight ruby %}
 package(:war).with :classes=>_('target/additional')
-}}}
+{% endhighlight %}
 
 If you want to include a different set of libraries other than the default:
 
-{{{!ruby
+{% highlight ruby %}
 package(:war).with :libs=>MYSQL_JDBC
-}}}
+{% endhighlight %}
 
 Both options accept a single value or an array.  The @:classes@ option accepts the name of a directory containing class files, initially set to @compile.target@ and @resources.target@.  The @:libs@ option accepts artifact specifications, file names and tasks, initially set to include everything in @compile.dependencies@.
 
 As you can guess, the package task has two attributes called @classes@ and @libs@; the @with@ method merely sets their value.  If you need more precise control over these arrays, you can always work with them directly, for example:
 
-{{{!ruby
+{% highlight ruby %}
 # Add an artifact to the existing set:
 package(:war).libs += artifacts(MYSQL_JDBC)
 # Remove an artifact from the existing set:
@@ -231,17 +238,18 @@
 # List all the artifacts:
 puts 'Artifacts included in WAR package:'
 puts package(:war).libs.map(&:to_spec)
-}}}
+{% endhighlight %}
+<!-- -->
 
 
-h2. Packaging AARs
+h2(#aar). Packaging AARs
 
 Axis2 service archives are similar to JAR's (compiled classes go into the root of the archive) but they can embed additional libraries under /lib and include @services.xml@ and WSDL files.
 
-{{{!ruby
+{% highlight ruby %}
 package(:aar).with(:libs=>'log4j:log4j:jar:1.1')
 package(:aar).with(:services_xml=>_('target/services.xml'), :wsdls=>_('target/*.wsdl'))
-}}}
+{% endhighlight %}
 
 The @libs@ attribute is a list of .jar artifacts to be included in the archive under /lib.  The default is no artifacts; compile dependencies are not included by default.
 
@@ -251,17 +259,18 @@
 
 If you already have WSDL files in the @src/main/axis2@ directory but would like to perform some filtering, for example, to set the HTTP port number, consider ignoring the originals and including only the filtered files, for example:
 
-{{{!ruby
+{% highlight ruby %}
 # Host name depends on environment.
 host = ENV['ENV'] == 'test' ? 'test.host' : 'ws.example.com'
 filter.from('src/main/axis2').into('target').
-  include('services.xml', '*.wsdl').using('http_port'=>'8080', 'http_host'=>host)
+  include('services.xml', '==*==.wsdl').using('http_port'=>'8080', 'http_host'=>host)
 package(:aar).wsdls.clear
-package(:aar).with(:services_xml=>_('target/services.xml'), :wsdls=>_('target/*.wsdl'))
-}}}
+package(:aar).with(:services_xml=>_('target/services.xml'), :wsdls=>_('target/==*==.wsdl'))
+{% endhighlight %}
+<!-- -->
 
 
-h2.  Packaging EARs
+h2(#ear).  Packaging EARs
 
 EAR packaging is slightly different from JAR/WAR packaging.  It's main purpose is to package components together, and so it includes special methods for handling component inclusion that take care to update application.xml and the component's classpath.
 
@@ -275,35 +284,35 @@
 
 This example shows two ways for adding components built by other projects:
 
-{{{!ruby
+{% highlight ruby %}
 package(:ear) << project('coolWebService').package(:war)
 package(:ear).add project('commonLib') # By default, the JAR package
-}}}
+{% endhighlight %}
 
 Adding a WAR package assumes it's a WAR component and treats it as such, but JAR packages can be any of three component types, so by default they are all treated as shared libraries.  If you want to add an EJB or Application Client component, you need to say so explicitly, either passing @:type=>package@, or by passing the component type in the @:type@ option.
 
 Here are three examples:
 
-{{{!ruby
+{% highlight ruby %}
 # Assumed to be a shared library.
 package(:ear).add 'org.springframework:spring:jar:2.6'
 # Component type mapped to package.
 package(:ear).add :ejb=>project('beanery')
 # Adding component with specific package type.
 package(:ear).add project('client'), :type=>:jar
-}}}
+{% endhighlight %}
 
 By default, WAR components are all added under the @/war@ path, and likewise, EJB components are added under the @/ejb@ path, shared libraries under @/lib@ and Application Client components under @/jar@.
 
 If you want to place components in different locations you can do so using the @:path@ option, or by specifying a different mapping between component types and their destination directory.  The following two examples are equivalent:
 
-{{{!ruby
+{% highlight ruby %}
 # Specify once per component.
 package(:ear).add project('coolWebService').package(:war), :path=>'coolServices'
 # Configure once and apply to all added components.
 package(:ear).dirs[:war] = 'coolServices'
 package(:ear) << project('coolWebService').package(:war)
-}}}
+{% endhighlight %}
 
 EAR packages include an @application.xml@ file in the @META-INF@ directory that describes the application and its components.  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.
 
@@ -313,55 +322,55 @@
 
 Again, by example:
 
-{{{!ruby
+{% highlight ruby %}
 package(:ear).display_name = 'MyCoolWebService'
 package(:ear).add project('coolWebService').package(:war), :context-root=>'coolness'
-}}}
+{% endhighlight %}
 
 If you need to disable the context root (e.g. for Portlets), set @context_root@ to @false@.
 
 
-h2.  Packaging Tars and GZipped Tars
+h2(#tar).  Packaging Tars and GZipped Tars
 
 Everything you know about working with ZIP files translates to Tar files, the two tasks are identical in more respect, so here we'll just go over the differences.
 
-{{{!ruby
+{% highlight ruby %}
 package(:tar).include _('target/docs'), 'README'
 package(:tgz).include _('target/docs'), 'README'
-}}}
+{% endhighlight %}
 
 The first line creates a Tar archive with the extension @.tar@, the second creates a GZipped Tar archive with the extension @.tgz@.
 
 In addition to packaging that includes the archive in the list of installed/released files, you can use the method @tar@ to create a @TarTask@. This task is similar to @ZipTask@, and introduces the @gzip@ attribute, which you can use to tell it whether to create a regular file, or GZip it.  By default the attribute it set to true (GZip) if the file name ends with either @.gz@ or @.tgz@.
 
 
-h2. Installing and Uploading
+h2(#install_upload). Installing and Uploading
 
 You can bring in the artifacts you need from remote repositories and install them in the local repositories.  Other projects have the same expectation, that your packages be their artifacts.
 
 So let's create these packages and install them in the local repository where other projects can access them:
 
-{{{!sh
+{% highlight sh %}
 $ buildr install
-}}}
+{% endhighlight %}
 
 If you changes your mind you can always:
 
-{{{!sh
+{% highlight sh %}
 $ buildr uninstall
-}}}
+{% endhighlight %}
 
 That works between projects you build on the same machine.  Now let's share these artifacts with other developers through a remote repository:
 
-{{{!sh
+{% highlight sh %}
 $ buildr upload
-}}}
+{% endhighlight %}
 
 Of course, you'll need to tell Buildr about the release server:
 
-{{{!ruby
+{% highlight ruby %}
 repositories.release_to = 'sftp://john:secret@release/usr/share/repo'
-}}}
+{% endhighlight %}
 
 This example uses the SFTP protocol.  In addition, you can use the HTTP protocol -- Buildr supports HTTP and HTTPS, Basic Authentication and uploads using PUT -- or point to a directory on your file system.
 
@@ -369,59 +378,60 @@
 
 Of course, you'll want to specify the release server URL in the Buildfile, but leave the username/password settings private in your local @buildr.rb@ file. Let's break up the release server settings:
 
-{{{!ruby
+{% highlight ruby %}
 # build.rb, loaded first
 repositories.release_to[:username] = 'john'
 repositories.release_to[:password] = 'secret'
 
 # Buildfile, loaded next
 repositories.release_to[:url] = 'sftp://release/usr/share/repo'
-}}}
+{% endhighlight %}
 
 The @upload@ task takes care of uploading all the packages created by your project, along with their associated POM files and MD5/SHA1 signatures (Buildr creates these for you).
 
 If you need to upload other files, you can always extend the @upload@ task and use @repositories.release_to@ in combination with @URI.upload@.  You can also extend it to upload to different servers, for example, to publish the documentation and test coverage reports to your site:
 
-{{{!ruby
+{% highlight ruby %}
 # We'll let some other task decide how to create 'docs'
 task 'upload'=>'docs' do
   uri = URI("sftp://#{username}:#{password}@var/www/docs")
   uri.upload file('docs')
 end
-}}}
+{% endhighlight %}
+<!-- -->
 
 
-h2. Packaging Sources and JavaDocs
+h2(#source_javadoc). Packaging Sources and JavaDocs
 
 IDEs can take advantage of source packages to help you debug and trace through compiled code.  We'll start with a simple example:
 
-{{{!ruby
+{% highlight ruby %}
 package :sources
-}}}
+{% endhighlight %}
 
 This one creates a ZIP package with the classifier "sources" that will contain all the source directories in that project, typically @src/main/java@, but also other sources generated from Apt, JavaCC, XMLBeans and friends.
 
 You can also generate a ZIP package with the classifier "javadoc" that contains the JavaDoc documentation for the project.  It uses the same set of documentation files generated by the project's @javadoc@ task, so you can use it in combination with the @javadoc@ method.  For example:
 
-{{{!ruby
+{% highlight ruby %}
 package :javadoc
 javadoc :windowtitle=>'Buggy but Works'
-}}}
+{% endhighlight %}
 
 By default Buildr picks the project's description for the window title.
 
 You can also tell Buildr to automatically create sources and JavaDoc packages in all the sub-projects that have any source files to package or document. Just add either or both of these methods in the top-level project:
 
-{{{!ruby
+{% highlight ruby %}
 package_with_sources
 package_with_javadoc
-}}}
+{% endhighlight %}
 
 You can also tell it to be selective using the @:only@ and @:except@ options.
 For example:
 
-{{{!ruby
+{% highlight ruby %}
 package_with_javadoc :except=>'la-web'
-}}}
+{% endhighlight %}
 
 We packaged the code, but will it actually work? Let's see "what the tests say":testing.html.

Copied: buildr/trunk/doc/projects.textile (from r752580, buildr/trunk/doc/pages/projects.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/projects.textile?p2=buildr/trunk/doc/projects.textile&p1=buildr/trunk/doc/pages/projects.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/projects.textile (original)
+++ buildr/trunk/doc/projects.textile Wed Mar 11 22:39:02 2009
@@ -1,6 +1,10 @@
-h1. Projects
+---
+layout: default
+title: Projects
+---
 
-h2. Starting Out
+
+h2(#starting). Starting Out
 
 In Java, most projects are built the same way: compile source code, run test cases, package the code, release it.  Rinse, repeat.
 
@@ -8,7 +12,7 @@
 
 The remainder of this guide deals with what it takes to build a project.  But first, let's pick up a sample project to work with.  We'll call it _killer-app_:
 
-{{{!ruby
+{% highlight ruby %}
 require 'buildr'
  
 VERSION_NUMBER = '1.0'
@@ -52,14 +56,14 @@
   package :javadoc
 
 end
-}}}
+{% endhighlight %}
 
 A project definition requires four pieces of information: the project name, group identifier, version number and base directory.  The project name ... do we need to explain why its necessary?  The group identifier and version number are used for packaging and deployment, we'll talk more about that in the "Packaging":packaging.html section.  The base directory lets you find files inside the project.
 
 Everything else depends on what that particular project is building.  And it all goes inside the project definition block, the piece of code that comes between @define <name> ..  do@ and @end@.
 
 
-h2. The Directory Structure
+h2(#dir_structure). The Directory Structure
 
 Buildr follows a convention we picked from years of working with Apache projects.
 
@@ -84,7 +88,7 @@
 When you start with a new project you won't see the @target@ or @reports@ directories.  Buildr creates these when it needs to.  Just know that they're there.
 
 
-h2. Naming And Finding Projects
+h2(#naming). Naming And Finding Projects
 
 Each project has a given name, the first argument you pass when calling @define@.  The project name is just a string, but we advise to stay clear of colon (@:@) and slashes (@/@ and @\@), which could conflict with other task and file names.  Also, avoid using common Buildr task names, don't pick @compile@ or @build@ for your project name.
 
@@ -96,7 +100,7 @@
 
 Let's illustrate this with a few examples:
 
-{{{!ruby
+{% highlight ruby %}
 puts projects.inspect
 => [project("killer-app"), project("killer-app:teh-api") ... ]
 
@@ -111,20 +115,16 @@
 
 puts project('killer-app').project('teh-api').inspect
 => project("killer-app:teh-api")
-}}}
-
-To see a list of all projects defined in your Buildfile:
+{% endhighlight %}
 
-{{{!sh
-$ buildr help:projects
-}}}
+To see a list of all projects defined in your Buildfile run @buildr help:projects@.
 
 
-h2. Running Project Tasks
+h2(#tasks). Running Project Tasks
 
 Most times, you run tasks like @build@ or @package@ that operate on the current project and recursively on its sub-projects.  The "current project" is the one that uses the current working directory.  So if you're in the @la-web/src@ directory looking at source files, _la-web_ is the current project.  For example: 
 
-{{{!sh
+{% highlight sh %}
 # build killer-app and all its sub-projects
 $ buildr build
 
@@ -135,11 +135,11 @@
 # switch to and package only la-web
 $ cd ../la-web
 $ buildr package
-}}}
+{% endhighlight %}
 
 You can use the project's full name to invoke one of its tasks directly, and it doesn't matter which directory you're in.  For example:
 
-{{{!sh
+{% highlight sh %}
 # build killer-app and all its sub-projects
 $ buildr killer-app:build
 
@@ -148,11 +148,11 @@
 
 # package only la-web
 $ buildr killer-app:la-web:package
-}}}
+{% endhighlight %}
 
 Buildr provides the following tasks that you can run on the current project, or on a specific project by prefixing them with the project's full name:
 
-{{{
+{% highlight text %}
 clean     # Clean files generated during a build
 compile   # Compile all projects
 build     # Build the project
@@ -162,21 +162,18 @@
 package   # Create packages
 test      # Run all test cases
 uninstall # Remove previously installed packages
-}}}
+{% endhighlight %}
 
-To see a list of all the tasks provided by Buildr:
+To see a list of all the tasks provided by Buildr run @buildr help:tasks@.
 
-{{{!sh
-$ buildr help:tasks
-}}}
 
-h2. Setting Project Properties
+h2(#properties). Setting Project Properties
 
 We mentioned the group identifier, version number and base directory.  These are project properties.  There are a few more properties we'll cover later on.
 
 There are two ways to set project properties.  You can pass them as a hash when you call @define@, or use accessors to set them on the project directly.  For example:
 
-{{{!ruby
+{% highlight ruby %}
 define 'silly', :version=>'1.0' do
   project.group = 'acme'
 end
@@ -185,12 +182,12 @@
 => 1.0
 puts project('silly').group
 => acme
-}}}
+{% endhighlight %}
 
 Project properties are inherited.  You can specify them once in the parent project, and they'll have the same value in all its sub-projects.  In the example, we only specify the version number once, for use in all sub-projects.
 
 
-h2. Resolving Paths
+h2(#paths). Resolving Paths
 
 You can run @buildr@ from any directory in your project.  To keep tasks consistent and happy, it switches over to the Buildfile directory and executes all the tasks from there, before returning back to your working directory. Your tasks can all rely on relative paths that start from the same directory as the Buildfile.
 
@@ -200,7 +197,7 @@
 
 For example:
 
-{{{!ruby
+{% highlight ruby %}
 # Relative to the current project
 path_to('src', 'main', 'java')
 
@@ -209,16 +206,16 @@
 
 # Relative to the teh-impl project
 project('teh-impl')._('src/main/java')
-}}}
-
+{% endhighlight %}
+<!-- -->
 
-h2. Defining The Project
+h2(#defining). Defining The Project
 
 The project definition itself gives you a lot of pre-canned tasks to start with, but that's not enough to build a project.  You need to specify what gets built and how, which dependencies to use, the packages you want to create and so forth.  You can configure existing tasks, extend them to do additional work, and create new tasks.  All that magic happens inside the project definition block.
 
 Since the project definition executes each time you run Buildr, you don't want to perform any work directly inside the project definition block.  Rather, you want to use it to specify how different build task work when you invoke them. Here's an example to illustrate the point:
 
-{{{!ruby
+{% highlight ruby %}
 define 'silly' do
   puts 'Running buildr'
 
@@ -226,7 +223,7 @@
     puts 'Building silly'
   end
 end
-}}}
+{% endhighlight %}
 
 Each time you run Buildr, it will execute the project definition and print out "Running buildr".  We also extend the @build@ task, and whenever we run it, it will print "Building silly".  Incidentally, @build@ is the default task, so if you run Buildr with no arguments, it will print both messages while executing the build.  If you run Buildr with a different task, say @clean@, it will only print the first message.
 
@@ -240,7 +237,7 @@
 
 In this example we define one project in terms of another, using the same dependencies, so we only need to specify them once:
 
-{{{!ruby
+{% highlight ruby %}
 define 'bar' do
   compile.with project('foo').compile.dependencies
 end
@@ -248,7 +245,7 @@
 define 'foo' do
   compile.with ..lots of stuff..
 end
-}}}
+{% endhighlight %}
 
 One last thing to remember.  Actually three, but they all go hand in hand.
 
@@ -261,7 +258,7 @@
 From outside the project you can reference a task by its full name, either @task('foo:do')@ or @project('foo').task('do')@.  If you need to reference a task defined outside the project from within the project, prefix it with "rake:", for example, @task('rake:globally-defined')@.
 
 
-h2. Writing Your Own Tasks
+h2(#your_own_tasks). Writing Your Own Tasks
 
 Of all the features Buildr provide, it doesn't have a task for making coffee. Yet.  If you need to write your own tasks, you get all the power of Rake: you can use regular tasks, file tasks, task rules and even write your own custom task classes.  Check out the "Rake documentation":http://docs.rubyrake.org/ for more information.
 

Copied: buildr/trunk/doc/recipes.textile (from r752580, buildr/trunk/doc/pages/recipes.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/recipes.textile?p2=buildr/trunk/doc/recipes.textile&p1=buildr/trunk/doc/pages/recipes.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/recipes.textile (original)
+++ buildr/trunk/doc/recipes.textile Wed Mar 11 22:39:02 2009
@@ -1,72 +1,80 @@
-h1. Recipes
+---
+layout: default
+title: Recipes
+---
 
 Commond recipes for Buildr, collected from the mailing list.
 
 
-h2.  Creating a classpath
+h2(#classpath).  Creating a classpath
 
 For Java, the classpath argument is simply a list of paths joined with an OS-specific path separator:
 
-{{{!ruby
+{% highlight ruby %}
 cp = paths.join(File::PATH_SEPARATOR)
-}}}
+{% endhighlight %}
 
 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
+{% highlight ruby %}
 tasks = Buildr.artifacts(specs)
-}}}
+{% endhighlight %}
 
 Next, map that list of tasks into list of file names (essentially calling @name@ on each task):
 
-{{{!ruby
+{% highlight ruby %}
 paths = tasks.map(&:name)
-}}}
+{% endhighlight %}
 
 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
+{% highlight ruby %}
 tasks = Buildr.artifacts(specs).each(&:invoke)
-}}}
+{% endhighlight %}
 
 So let's roll this all into a single line:
 
-{{{!ruby
+{% highlight ruby %}
 cp = Buildr.artifacts(specs).each(&:invoke).map(&:name).join(File::PATH_SEPARATOR)
-}}}
+{% endhighlight %}
+<!-- -->
 
 
 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
+<notextile>
+{% highlight yaml %}
 development: &common
   db: oracle
   port: 8080
 test: *common
 production: *common
-}}}
+{% endhighlight %}
+</notextile>
 
 If you have two elements that are almost identical, you can merge the values of one element into another (@<<@), for example:
 
-{{{!yaml
+{% highlight yaml %}
 development: &common
   db: hsql
   jdbc: hsqldb:mem:devdb
 test:
   <<: *common
   jdbc: hsqldb:file:testdb
-}}}
+{% endhighlight %}
+<!-- -->
 
 
 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:
 
-{{{!
+{% highlight text %}
 $ export JAVA_OPTS=-client
-}}}
+{% endhighlight %}
+<!-- -->
 
 
 h2.  Continuous Integration with Atlassian Bamboo

Copied: buildr/trunk/doc/settings_profiles.textile (from r752580, buildr/trunk/doc/pages/settings_profiles.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/settings_profiles.textile?p2=buildr/trunk/doc/settings_profiles.textile&p1=buildr/trunk/doc/pages/settings_profiles.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/settings_profiles.textile (original)
+++ buildr/trunk/doc/settings_profiles.textile Wed Mar 11 22:39:02 2009
@@ -1,30 +1,33 @@
-h1. Settings/Profiles
+---
+layout: default
+title: Settings/Profiles
+---
 
 
-h2.  Environment Variables
+h2(#env_vars).  Environment Variables
 
 Buildr uses several environment variables that help you control how it works. Some environment variables you will only set once or change infrequently.  You can set these in your profile, OS settings or any tool you use to launch Buildr (e.g. continuous integration).
 
 For example:
 
-{{{!sh
+{% highlight sh %}
 $ export HTTP_PROXY=http://myproxy:8080
-}}}
+{% endhighlight %}
 
 There are other environment variables you will want to set when running Buildr, for example, to do a full build without running the tests:
 
-{{{!sh
+{% highlight sh %}
 $ buildr test=no
-}}}
+{% endhighlight %}
 
 For convenience, when you set environment variables on the command line, the variable name is case insensitive, you can use either @test=no@ or @TEST=no@. Any other way (@export@, @ENV@, etc) the variable names are case sensitive.
 
 You can also set environment variables from within your Buildfile.  For example, if you discover that building your project requires gobs of JVM heap space, and you want all other team members to run with the same settings:
 
-{{{!ruby
+{% highlight ruby %}
 # This project builds a lot of code.
 ENV['JAVA_OPTS'] ||= '-Xms1g -Xmx1g'
-}}}
+{% endhighlight %}
 
 Make sure to set any environment variables at the very top of the Buildfile, above any Ruby statement (even @require@).
 
@@ -48,13 +51,14 @@
 
 Some extensions may use additional environment variables, and of course, you can always add your own.  This example uses two environment variables for specifying the username and password:
 
-{{{!ruby
+{% highlight ruby %}
 repositories.upload_to[:username] = ENV['USERNAME']
 repositories.upload_to[:password] = ENV['PASSWORD']
-}}}
+{% endhighlight %}
+<!-- -->
 
 
-h2. Personal Settings
+h2(#personal). Personal Settings
 
 Some things clearly do not belong in the Buildfile.  For example, the username and password you use to upload releases.  If you're working in a team or on an open source project, you'd want to keep these in a separate place.
 
@@ -64,7 +68,7 @@
 
 Here's an example @settings.yaml@:
 
-{{{!yaml
+{% highlight yaml %}
 # The repositories hash is read automatically by buildr.
 repositories:
 
@@ -87,26 +91,27 @@
   server: jabber.company.com
   usr: notifier@company-jabber.com
   pwd: secret
-}}}
+{% endhighlight %}
 
 Later your buildfile or addons can reference user preferences using the  hash returned by the @Buildr.settings.user@ accessor.
 
-{{{!ruby
+{% highlight ruby %}
 task 'relase-notification' do
  usr, pwd, server = settings.user['im'].values_at('usr', 'pwd', 'server')
  jabber = JabberAPI.new(server, usr, pwd)
  jabber.msg("We are pleased to announce the last stable version #{VERSION}")
 end
-}}}
+{% endhighlight %}
+<!-- -->
 
 
-h2. Build Settings
+h2(#build). Build Settings
 
 Build settings are local to the project being built, and 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.
 
 They help keep the buildfile and build.yaml file simple and readable, working to the advantages of each one.  Example for build settings are gems, repositories and artifacts used by that build.
 
-{{{!yaml
+{% highlight yaml %}
 # This project requires the following ruby gems, buildr addons
 gems: 
   # Suppose we want to notify developers when testcases fail.
@@ -133,22 +138,22 @@
 
 jira: 
   uri: https://jira.corp.org
-}}}
+{% endhighlight %}
 
 When buildr is loaded, required ruby gems will be installed if needed, thus adding features like the imaginary twitter notifier addon.
 
 Artifacts defined on @build.yaml@ can be referenced on your buildfile by supplying the ruby symbol to the @Buildr.artifact@ and @Buildr.artifacts@ methods.  The @compile.with@, @test.with@ methods can also be given these names.
 
-{{{!ruby
+{% highlight ruby %}
 define 'my_project' do 
   compile.with artifacts(:log4j, :j2ee)
   test.with :spring, :j2ee
 end
-}}}
+{% endhighlight %}
 
 Build settings can be retreived using the @Buildr.settings.build@ accessor.
 
-{{{!ruby
+{% highlight ruby %}
  task 'create_patch' do 
    patch = Git.create_patch :interactive => true
    if patch && agree("Would you like to request inclusion of #{patch}")
@@ -156,9 +161,11 @@
      jira.create(:improvement, patch.summary, :attachment => patch.blob)
    end
  end
-}}}
+{% endhighlight %}
+<!-- -->
 
-h2. Non constant settings
+
+h2(#variable). Non constant settings
 
 Before loading the Buildfile, Buildr will attempt to load two other files: the @buildr.rb@ file it finds in your home directory, followed by the @buildr.rb@ file it finds in the build directory.
 
@@ -166,44 +173,45 @@
 
 Here's an example @buildr.rb@:
 
-{{{!ruby
+{% highlight ruby %}
 # Only I should know that
 repositories.upload_to[:username] = 'assaf'
 repositories.upload_to[:password] = 'supersecret'
 # Search here first, it's faster
 repositories.remote << 'http://inside-the-firewall'
-}}} 
+{% endhighlight %} 
+<!-- -->
 
 
-h2. Environments
+h2(#environments). Environments
 
 One common use case is adapting the build to different environments.  For example, to compile code with debugging information during development and testing, but strip it for production.  Another example is using different databases for development, testing and production, or running services at different URLs.
 
 So let's start by talking about the build environment.  Buildr has a global attributes that indicates which environment it's running in, accessible from the @environment@ method.  You can set the current build environment in one of two ways.  Using the @-e/--environment@ command line option:
 
-{{{!sh
+{% highlight sh %}
 $ buildr -e test
 (in /home/john/project, test)
-}}}
+{% endhighlight %}
 
 Or by setting the environment variable @BUILDR_ENV@:
 
-{{{!
+{% highlight text %}
 $ export BUILDR_ENV=production
 $ buildr
 (in /home/john/project, production)
-}}}
+{% endhighlight %}
 
 Unless you tell it otherwise, Buildr assumes you're developing and sets the environment to @development@.
 
 Here's a simple example for handling different environments within the Buildfile:
 
-{{{!ruby
+{% highlight ruby %}
 project 'db-module' do
   db = (environment == 'production' ? 'oracle' : 'hsql')
   resources.from(_("src/main/#{db}"))
 end
-}}}
+{% endhighlight %}
 
 We recommend picking a convention for your different environments and following it across all your projects.  For example:
 
@@ -213,7 +221,7 @@
 | production    | Building for release/production. |
 
 
-h2.  Profiles
+h2(#profiles).  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.
 
@@ -221,7 +229,7 @@
 
 For example, to support three different database configurations, we could write:
 
-{{{!yaml
+{% highlight yaml %}
 # HSQL, don't bother storing to disk.
 development:
   db: hsql
@@ -236,11 +244,11 @@
 production:
   db: oracle
   jdbc: oracle:thin:@bigstrong:1521:mighty
-}}}
+{% endhighlight %}
 
 Here's a simple example for a buildfile that uses the profile information:
 
-{{{!ruby
+{% highlight ruby %}
 project 'db-module' do
   # Copy SQL files specific for the database we're using,
   # for example, everything under src/main/hsql.
@@ -248,7 +256,7 @@
   # Set the JDBC URL in copied resource files (config.xml needs this).
   resources.filter.using :jdbc=>Buildr.settings.profile['jdbc']
 end
-}}}
+{% endhighlight %}
 
 The @profile@ method returns the current profile, selected based on the current "environment":#environments.  You can get a list of all profiles by calling @profiles@.
 
@@ -258,7 +266,7 @@
 
 YAML allows you to use anchors (@&@), similar to ID attributes in XML, reference the anchored element (@*@) elsewhere, and merge one element into another (@<<@).  For example:
 
-{{{!yaml
+{% highlight yaml %}
 # We'll reference this one as common.
 development: &common
   db: hsql
@@ -269,6 +277,7 @@
 test:
   <<: *common
   jdbc: hsqldb:file:testdb
-}}}
+{% endhighlight %}
+
 
 You can "learn more about YAML here":http://www.yaml.org, and use this handy "YAML quick reference":http://www.yaml.org/refcard.html.

Copied: buildr/trunk/doc/testing.textile (from r752580, buildr/trunk/doc/pages/testing.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/testing.textile?p2=buildr/trunk/doc/testing.textile&p1=buildr/trunk/doc/pages/testing.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/testing.textile (original)
+++ buildr/trunk/doc/testing.textile Wed Mar 11 22:39:02 2009
@@ -1,9 +1,13 @@
-h1. Testing
+---
+layout: default
+title: Testing
+---
+
 
 Untested code is broken code, so we take testing seriously.  Off the bat you get to use either JUnit or TestNG for writing unit tests and integration tests. And you can also add your own framework, or even script tests using Ruby.  But= first, let's start with the basics.
 
 
-h2. Writing Tests
+h2(#writing). Writing Tests
 
 Each project has a @TestTask@ that you can access using the @test@ method. @TestTask@ reflects on the fact that each project has one task responsible for getting the tests to run and acting on the results.  But in fact there are several tasks that do all the work, and a @test@ task coordinates all of that.
 
@@ -18,35 +22,35 @@
 Different languages use different test frameworks.  You can find out more about available test frameworks in the "Languages":languages.html section.
 
 
-h2. Excluding Tests and Ignoring Failures
+h2(#ignoring). Excluding Tests and Ignoring Failures
 
 If you have a lot of tests that are failing or just hanging there collecting dusts, you can tell Buildr to ignore them.  You can either tell Buildr to only run specific tests, for example:
 
-{{{!ruby
+{% highlight ruby %}
 test.include 'com.acme.tests.passing.*'
-}}}
+{% endhighlight %}
 
 Or tell it to exclude specific tests, for example:
 
-{{{!ruby
+{% highlight ruby %}
 test.exclude '*FailingTest', '*FailingWorseTest'
-}}}
+{% endhighlight %}
 
 Note that we're always using the package qualified class name, and you can use star (@*@) to substitute for any set of characters.
 
 When tests fail, Buildr fails the @test@ task.  This is usually a good thing, but you can also tell Buildr to ignore failures by resetting the @:fail_on_failure@ option:
 
-{{{!ruby
+{% highlight ruby %}
 test.using :fail_on_failure=>false
-}}}
+{% endhighlight %}
 
 Besides giving you a free pass to ignore failures, you can use it for other causes, for example, to be somewhat forgiving:
 
-{{{!ruby
+{% highlight ruby %}
 test do
   fail 'More than 3 tests failed!' if test.failed_tests.size > 3
 end
-}}}
+{% endhighlight %}
 
 The @failed_tests@ collection holds the names of all classes with failed tests. And there's @classes@, which holds the names of all test classes.  Ruby arithmetic allows you to get the name of all passed test classes with a simple @test.classes – test.failed_tests@.  We'll let you imagine creative use for these two.
 
@@ -55,49 +59,49 @@
 
 It's a good idea to run tests every time you change the source code, so we wired the @build@ task to run the @test@ task at the end of the build.  And conveniently enough, the @build@ task is the default task, so another way to build changes in your code and run your tests:
 
-{{{!sh
+{% highlight sh %}
 $ buildr
-}}}
+{% endhighlight %}
 
 That only works with the local @build@ task and any local task that depends on it, like @package@, @install@ and @upload@.  Each project also has its own @build@ task that does not invoke the @test@ task, so @buildr build@ will run the tests cases, but @buildr foo:build@ will not.
 
 While it's a good idea to always run your tests, it's not always possible. There are two ways you can get @build@ to not run the @test@ task.  You can set the environment variable @test@ to @no@ (but @skip@ and @off@ will also work). You can do that when running Buildr:
 
-{{{!sh
+{% highlight sh %}
 $ buildr test=no
-}}}
+{% endhighlight %}
 
 Or set it once in your environment:
 
-{{{!sh
+{% highlight sh %}
 $ export TEST=no
 $ buildr
-}}}
+{% endhighlight %}
 
 If you're feeling really adventurous, you can also disable tests from your Buildfile or @buildr.rb@ file, by setting @options.test = false@. We didn't say it's a good idea, we're just giving you the option.
 
 The @test@ task is just smart enough to run all the tests it finds, but will accept include/exclude patterns.  Often enough you're only working on one broken test and you only want to run that one test.  Better than changing your Buildfile, you can run the @test@ task with a pattern.  For example:
 
-{{{!sh
+{% highlight sh %}
 $ buildr test:KillerAppTest
-}}}
+{% endhighlight %}
 
 Buildr will then run only tests that match the pattern @KillerAppTest@.  It uses pattern matching, so @test:Foo@ will run @com.acme.FooTest@ and @com.acme.FooBarTest@.  With Java, you can use this to pick a class name, or a package name to run all tests in that package, or any such combination.  In fact, you can specify several patterns separated with commas.  For example:
 
-{{{!sh
+{% highlight sh %}
 $ buildr test:FooTest,BarTest
-}}}
+{% endhighlight %}
 
 As you probably noticed, Buildr will stop your build at the first test that fails.  We think it's a good idea, except when it's not.  If you're using a continuous build system, you'll want a report of all the failed tests without stopping at the first failure.  To make that happen, set the environment variable @test@ to "all", or the Buildr @options.test@ option to @:all@.  For example:
 
-{{{!sh
+{% highlight sh %}
 $ buildr package test=all
-}}}
+{% endhighlight %}
 
 We're using @package@ and not @build@ above.  When using a continuous build system, you want to make sure that packages are created, contain the right files, and also run the integration tests.
 
 
-h2. Integration Tests
+h2(#integration). Integration Tests
 
 So far we talked about unit tests.  Unit tests are run in isolation on the specific project they test, in an isolated environment, generally with minimal setup and teardown.  You get a sense of that when we told you tests run after the @build@ task, and include JMock in the dependency list.
 
@@ -105,44 +109,44 @@
 
 You write integration tests much the same way as you write unit tests, using @test.compile@ and @test.resources@.  However, you need to tell Buildr that your tests will execute during integration test.  To do so, add the following line in your project definition:
 
-{{{!ruby
+{% highlight ruby %}
 test.using :integration
-}}}
+{% endhighlight %}
 
 Typically you'll use unit tests in projects that create internal modules, such as JARs, and integration tests in projects that create components, such as WARs and EARs.  You only need to use the @:integration@ option with the later.
 
 To run integration tests on the current project:
 
-{{{!sh
+{% highlight sh %}
 $ buildr integration
-}}}
+{% endhighlight %}
 
 You can also run specific tests cases, for example:
 
-{{{!sh
+{% highlight sh %}
 $ buildr integration:ClientTest
-}}}
+{% endhighlight %}
 
 If you run the @package@ task (or any task that depends on it, like @install@ and @upload@), Buildr will first run the @build@ task and all its unit tests, and then create the packages and run the integration tests.  That gives you full coverage for your tests and ready to release packages.  As with unit tests, you can set the environment variable @test@ to "no" to skip integration tests, or "all" to ignore failures.
 
 
-h2. Using Setup and Teardown
+h2(#setup_teardown). Using Setup and Teardown
 
 Some tests need you to setup an environment before they run, and tear it down afterwards.  The test frameworks (JUnit, TestNG) allow you to do that for each test.  Buildr provides two additional mechanisms for dealing with more complicated setup and teardown procedures.
 
 Integration tests run a setup task before the tests, and a teardown task afterwards.  You can use this task to setup a Web server for testing your Web components, or a database server for testing persistence.  You can access either task by calling @integration.setup@ and @integration.teardown@.  For example:
 
-{{{!ruby
+{% highlight ruby %}
 integration.setup { server.start ; server.deploy }
 integration.teardown { server.stop }
-}}}
+{% endhighlight %}
 
 Depending on your build, you may want to enhance the setup/teardown tasks from within a project, for example, to populate the database with data used by that project's test, or from outside the project definition, for example, to start and stop the Web server.
 
 Likewise, each project has its own setup and teardown tasks that are run before and after tests for that specific project.  You can access these tasks using @test.setup@ and @test.teardown@.
 
 
-h2. Testing Your Build
+h2(#checks). Testing Your Build
 
 So you got the build running and all the tests pass, binaries are shipping when you find out some glaring omissions.  The license file is empty, the localized messages for Japanese are missing, the CSS files are not where you expect them to be.  The fact is, some errors slip by unit and integration tests.  So how do we make sure the same mistake doesn't happen again?
 
@@ -150,7 +154,7 @@
 
 You use the @check@ method to express and expectation.  Buildr will then run all these expectations against your project, and fail at the first expectation that doesn't match.  An expectation says three things.  Let's look at a few examples:
 
-{{{!ruby
+{% highlight ruby %}
 check package(:war), 'should exist' do
   it.should exist
 end
@@ -172,17 +176,17 @@
 check file('target/classes/killerapp/Code.class'), 'should exist' do
   it.should exist
 end
-}}}
+{% endhighlight %}
 
 The first argument is the subject, or the project if you skip the first argument.  The second argument is the description, optional, but we recommend using it.  The method @it@ returns the subject.
 
 You can also write the first expectation like this:
 
-{{{!ruby
+{% highlight ruby %}
 check do
   package(:jar).should exist
 end
-}}}
+{% endhighlight %}
 
 We recommend using the subject and description, they make your build easier to read and maintain, and produce better error messages.
 
@@ -202,7 +206,7 @@
 Buildr expectations are based on RSpec.  "RSpec":http://rspec.info/ is the behavior-driven development framework we use to test Buildr itself.  Check the RSpec documentation if want to see all the supported matchers, or want to write your own.
 
 
-h2. Behaviour-Driven Development
+h2(#bdd). Behaviour-Driven Development
 
 Buildr supports several Behaviour-Driven Development(BDD) frameworks for testing your projects.  Buildr follows each framework naming conventions, searching for files under the @src/spec/{lang}@ directory.
 

Copied: buildr/trunk/doc/troubleshooting.textile (from r752580, buildr/trunk/doc/pages/troubleshooting.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/troubleshooting.textile?p2=buildr/trunk/doc/troubleshooting.textile&p1=buildr/trunk/doc/pages/troubleshooting.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/troubleshooting.textile (original)
+++ buildr/trunk/doc/troubleshooting.textile Wed Mar 11 22:39:02 2009
@@ -1,38 +1,45 @@
-h1. Troubleshooting
+---
+layout: default
+title: Troubleshooting
+---
 
 Common troubleshooting tips collected from the mailing list.
 
 
-h2.  Running out of heap space
+h2(#heap).  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
+{% highlight sh %}
 $ export "JAVA_OPTS=-Xms1g -Xmx1g"
 $ buildr compile
-}}}
+{% endhighlight %}
 
 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
+<notextile>
+{% highlight ruby %}
 ENV['JAVA_OPTS'] = '-Xms1g -Xmx1g'
-}}}
+{% endhighlight %}
+</notextile>
 
 
-h2.  RJB fails to compile
+h2(#rjb_fails).  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
+<notextile>
+{% highlight sh %}
 $ sudo env JAVA_HOME=$JAVA_HOME gem install buildr
-}}}
+{% endhighlight %}
+</notextile>
 
 
-h2.  Segmentation Fault when running Java code
+h2(#seg_fault).  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.
 
@@ -40,29 +47,31 @@
 
 Make sure @JAVA_HOME@ and @/usr/bin/javac@ both point to the same JDK:
 
-{{{!sh
+<notextile>
+{% highlight sh %}
 echo $JAVA_HOME
 ls -l /usr/bin/javac
-}}}
+{% endhighlight %}
+</notextile>
 
 *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
+h2(#danglings).  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
+{% highlight ruby %}
 compile.with 'org.apache.axis2:axis2:jar:1.2',
 test.with 'log4j:log4j:jar:1.1'
-}}}
+{% endhighlight %}
 
 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
+h2(#missing_poms).  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.
 
@@ -74,7 +83,8 @@
 
 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
+<notextile>
+{% highlight ruby %}
 artifact 'axis:axis-jaxrpc:pom:1.3' do |task|
   write task.name, <<-POM
     <project>
@@ -85,19 +95,20 @@
     </project>
   POM
 end
-}}}
+{% endhighlight %}
+</notextile>
 
 
-h2. Buildr fails to run after install with a "stack level too deep (SystemStackError)" error
+h2(#stack_level). 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
+{% highlight sh %}
 require 'buildr'
-}}}
+{% endhighlight %}
 
 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).
\ No newline at end of file
+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).

Copied: buildr/trunk/doc/whats_new.textile (from r752580, buildr/trunk/doc/pages/whats_new.textile)
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/whats_new.textile?p2=buildr/trunk/doc/whats_new.textile&p1=buildr/trunk/doc/pages/whats_new.textile&r1=752580&r2=752665&rev=752665&view=diff
==============================================================================
--- buildr/trunk/doc/pages/whats_new.textile (original)
+++ buildr/trunk/doc/whats_new.textile Wed Mar 11 22:39:02 2009
@@ -1,6 +1,9 @@
-h1.  What's New
+---
+layout: default
+title: What's new
+---
 
-h2.  Buildr 1.3.3
+h2(#1.3.3).  Buildr 1.3.3
 
 * Support for "JtestR":http://jtestr.codehaus.org/ test framework.
 * Support for "Emma":http://emma.sourceforge.net/ code coverage tool.
@@ -11,7 +14,7 @@
 * 27 other bug fixes and minor changes, see the "CHANGELOG":changelog.html for full details.
 
 
-h2.  Buildr 1.3.2
+h2(#1.3.2).  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.
@@ -25,7 +28,7 @@
 * Fixed: Installation instructions updated for RubyGems 1.2.0.
 
 
-h2.  Buildr 1.3.1
+h2(#1.3.1).  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).
@@ -37,7 +40,7 @@
 * Added the jibx_bind method to use JiBX for Java<=>XML binding (by David Peterson).
 
 
-h2.  Buildr 1.3
+h2(#1.3).  Buildr 1.3
 
 h3.  Multiple Languages
 
@@ -78,9 +81,9 @@
 
 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
+{% highlight ruby %}
 package :zip, :file=>_('target/interesting.zip')
-}}}
+{% endhighlight %}
 
 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.
 
@@ -99,10 +102,10 @@
 
 This example shows two ways for adding components built by other projects:
 
-{{{!ruby
+{% highlight ruby %}
 package(:ear) << project('coolWebService').package(:war)
 package(:ear).add project('commonLib') # By default, the JAR package
-}}}
+{% endhighlight %}
 
 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.
 
@@ -144,7 +147,7 @@
 
 For example, to support three different database configurations, we could write:
 
-{{{!yaml
+{% highlight yaml %}
 # HSQL, don't bother storing to disk.
 development:
   db: hsql
@@ -153,13 +156,13 @@
 # Make sure we're not messing with bigstrong.
 test:
   db: oracle
-  jdbc: oracle:thin:@localhost:1521:test
+  jdbc: oracle:thin:localhost:1521:test
 
 # The real deal.
 production:
   db: oracle
-  jdbc: oracle:thin:@bigstrong:1521:mighty
-}}}
+  jdbc: oracle:thin:bigstrong:1521:mighty
+{% endhighlight %}
 
 You can also use profiles to specify default filters for the "@resources@ task":building.html#resources.
 
@@ -174,7 +177,7 @@
 
 For example:
 
-{{{!yaml
+{% highlight yaml %}
 # The repositories hash is read automatically by buildr.
 repositories:
 
@@ -192,7 +195,7 @@
   server: jabber.company.com
   usr: notifier@company-jabber.com
   pwd: secret
-}}}
+{% endhighlight %}
 
 "Read more ...":settings_profiles.html#personal_settings
 
@@ -200,7 +203,7 @@
 
 For example:
 
-{{{!yaml
+{% highlight yaml %}
 # This project requires the following ruby gems, buildr addons
 gems: 
   # Suppose we want to notify developers when testcases fail.
@@ -219,7 +222,7 @@
 # Of course project settings can be defined here
 jira: 
   uri: https://jira.corp.org
-}}}
+{% endhighlight %}
 
 "Read more ...":settings_profiles.html#build_settings
 
@@ -232,7 +235,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.
@@ -240,7 +243,7 @@
   # we test with ruby mock objects
   - mocha
   - ci_reporter
-}}}
+{% endhighlight %}
 
 "Read more ...":more_stuff.html#using_gems
 
@@ -249,22 +252,22 @@
 
 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.
 
 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.
 
@@ -275,19 +278,19 @@
 
 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.
 

Modified: buildr/trunk/rakelib/doc.rake
URL: http://svn.apache.org/viewvc/buildr/trunk/rakelib/doc.rake?rev=752665&r1=752664&r2=752665&view=diff
==============================================================================
--- buildr/trunk/rakelib/doc.rake (original)
+++ buildr/trunk/rakelib/doc.rake Wed Mar 11 22:39:02 2009
@@ -34,81 +34,42 @@
 
 
 begin
-  require 'docter'
-  require 'docter/server'
+  require 'jekyll'
 
-  #Docter.filter_for(:footnote) do |html|
-  #  html.gsub(/<p id="fn(\d+)">(.*?)<\/p>/, %{<p id="fn\\1" class="footnote">\\2</p>})
-  #end
-
-  collection = Docter.collection(spec.name).using('doc/site.toc.yaml').include('doc/pages', 'LICENSE', 'CHANGELOG')
-  # TODO:  Add coverage reports when we get them to run.
-  template   = Docter.template('doc/site.haml').include('doc/css', 'doc/images', 'doc/scripts', 'rdoc')
-
-  desc 'Run Docter server on port 3000'
-  Docter::Rake.serve 'docter', collection, template, :port=>3000
-
-  Docter::Rake.generate '_print',
-    Docter.collection(spec.name).using('doc/print.toc.yaml').include('doc/pages'),
-    Docter.template('doc/print.haml').include('doc/css', 'doc/images'), :one_page
-
-  file('buildr.pdf'=>'_print') do |task|
-    sh 'prince', '_print/index.html', '-o', task.name, '--media=print' do |ok, res|
-      fail 'Failed to create PDF, see errors above' unless ok
-    end
+  task '_site'=>['doc'] do
+    Jekyll.pygments = true
+    Jekyll.process 'doc', '_site'
   end
 
-  desc 'Generate Web site in directory site'
-  Docter::Rake.generate '_site', collection, template
-
-  task '_site/buildr.pdf'=>'buildr.pdf' do
-    cp 'buildr.pdf', '_site'
-  end
-  task '_site/specs.html'=>'spec' do
-    cp '_reports/specs.html', '_site'
-  end
-  task '_site/coverage'=>'coverage' do
-    cp_r '_reports/coverage', '_site'
-  end
-
-  task 'site'=>['_site', '_site/buildr.pdf', '_site/specs.html', '_site/coverage'] do
-    print 'Checking that we have site documentation, RDoc and PDF ... '
-    fail 'No PDF generated, you need to install PrinceXML!' unless File.exist?('_site/buildr.pdf')
-    fail 'No RDocs in site directory' unless File.exist?('_site/rdoc/files/lib/buildr_rb.html')
-    fail 'No site documentation in site directory' unless File.exist?('_site/index.html')
-    fail 'No specifications in site directory' unless File.exist?('_site/specs.html')
-    fail 'No coverage report in site directory' unless File.exist?('_site/coverage')
-    puts 'OK'
+rescue LoadError
+  puts "Buildr uses the mojombo-jekyll to generate the Web site. You can install it by running rake setup"
+  task 'setup' do
+    install_gem 'mojombo-jekyll', :source=>'http://gems.github.com'
+    sh "#{sudo_needed? ? 'sudo ' : nil}easy_install Pygments"
   end
+end
 
 
-  # Publish prerequisites to Web site.
-  task 'site_publish'=>'site' do
-    target = "people.apache.org:/www/#{spec.name}.apache.org"
-    puts "Uploading new site to #{target} ..."
-    sh "rsync --progress --recursive --delete _site/ #{target.inspect}/"
-    sh "ssh people.apache.org chmod -R g+w /www/#{spec.name}.apache.org/*"
-    puts "Done"
-  end
-
+desc "Build a copy of the Web site in the ./_site"
+task 'site'=>['_site', 'rdoc', 'spec', 'coverage'] do
+  cp_r 'rdoc', '_site'
+  fail 'No RDocs in site directory' unless File.exist?('_site/rdoc/files/lib/buildr_rb.html')
+  cp '_reports/specs.html', '_site'
+  cp_r '_reports/coverage', '_site'
+  fail 'No coverage report in site directory' unless File.exist?('_site/coverage/index.html')
+  puts 'OK'
+end
 
-  desc 'Produce PDF'
-  task 'pdf'=>'_print/buildr.pdf' do |task|
-    sh 'open', '_print/buildr.pdf'
-  end
 
-  task 'clobber' do
-    rm_rf '_site' if File.exist?('_site')
-    rm_rf '_print' if File.exist?('_print')
-    rm_rf 'buildr.pdf' if File.exist?('buildr.pdf')
-  end
+# Publish prerequisites to Web site.
+task 'site_publish'=>'site' do
+  target = "people.apache.org:/www/#{spec.name}.apache.org"
+  puts "Uploading new site to #{target} ..."
+  sh "rsync --progress --recursive --delete _site/ #{target.inspect}/"
+  sh "ssh people.apache.org chmod -R g+w /www/#{spec.name}.apache.org/*"
+  puts "Done"
+end
 
-rescue LoadError
-  puts 'Please run rake setup to install the Docter document generation library'
-  task 'setup' do
-    install_gem 'docter'#, '~>1.1.3'
-  end
-  task 'stage:check' do
-    fail 'Please run rake setup to install the Docter document generation library'
-  end
+task 'clobber' do
+  rm_rf '_site' if File.exist?('_site')
 end