Barbler: Integrating JRuby Warbler into Apache Builder

ijonas — Fri, 25 Sep 2009 21:54:14 +0000

After having used Apache Builder for a week and extracted our Warbler-code into a bonafide extension, I’m sharing it with the community under the fetching name Barbler.

Barbler integrates itself between the build and packaging stages of the Apache Builder lifecycle and makes calls into Warbler to automate WAR-file creation. Now Warbler does a really good job for packaging standalone Rails apps. Unfortunately I needed something more integrated into our application build process, that pulls in our Spring Framework-based Java code, Scala code, and Rails application and produces a single WAR-file containing all dependent libraries, Rails code, XML deployment descriptors and Java class files. Apache Builder does everything other than the Rails-packaging. Barbler steps to provide that missing step.

Create a barbler.rb file in your project folder, which also contains your buildfile and copy the following contents into it:

# Barbler 
# is an Apache Builder extension to integrate the JRuby Warbler gem.
# For tips on how to use Barbler checkout http://www.denofubiquity.com/ruby/barbler/
# 
# This code is licensed under the Apache License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0.txt)
# Please distribute Barbler code with this code intact.
# (c) Ijonas Kisselbach 2009
 
require 'warbler'
 
module Barbler
  include Extension
 
  first_time do
    # Define task not specific to any projet.
    desc 'Warbles Rails sourcecode tree into a staging folder'
    Project.local_task('warble' => 'build') { |name| "Warbling #{name}" }   
  end
 
  before_define do |project|    
    project.task('warble'=>project.task('build'))
    project.group ||= project.parent && project.parent.group || project.name
    project.version ||= project.parent && project.parent.version    
  end
 
  # To use this method in your project:
  #   warble(:rails => path_to(:rails), :tasks => [:app, :public])
  def warble(*args)
    options = args.pop
    rails_path = options[:rails]
    warble_tasks = options[:tasks]
 
    # Define the warble task for this particular project.
    Rake::Task.define_task 'warble' do |task|
      # get all the important components from the Rails GUI into the staging directory
      puts "Warbling #{rails_path}"
      Dir.chdir(rails_path) do
        warble_cfg = eval(File.open("config/warble.rb") {|f| f.read})
        Warbler::Task.new(:war, warble_cfg)
        warble_tasks.each {|task| Rake::Task["war:#{task}"].invoke}
      end
    end
  end
 
end
 
class Buildr::Project
  include Barbler
end

Add the folllowing line to the top of your buildfile:

warble(:rails => path_to(:rails), :tasks => [:app, :public])

You can then define your warble task using the following line

warble(:rails => path_to(:rails), :tasks => [:app, :public])

whereby the first parameter is a path string to where your Rails code is located. You may locate your code in src/main/rails in which case you’d use

warble(:rails => path_to(:source, :main, :rails), :tasks => [:app, :public])

The second parameter is the list of Warbler tasks that you’d like to have executed. See the Warbler documentation for more help, or check out the Warbler source code – it’s very readable.

CouchDB Presentation at Railscamp UK

ijonas — Wed, 20 Aug 2008 21:29:27 +0000

I’ve been playing around with and kicking the tyres of CouchDB for a couple of weeks and I’m truly excited about the project. If I was to use tags to describe CouchDB I’d use the following:

apache, opensource, documents, metadata, database, json, javascript, REST, addressability, horizontal scaling, erlang.

So I found myself at Railscamp UK on the weekend without a ruby+rails topic to really talk about during the presentations part of the camp. I’m still a noob wrt. Rails, you see. Realising that CouchDB is relevant to most web developers because most developers deal with document-based content at some point and that Ruby, Rails, and Erlang are kindda like the current bratpack (in a John Hughes-sense) of computer languages, I thought it would be a great little topic for a 15-minute presentation.

So I thought I share the slides and some of the code I hacked up on the weekend. First of all the slides…

(click me)

You can play about with some sample code that was expanded upon after the presentation. Here’s a little helper class to interface into CouchDB using JSON and HTTP:

require 'rubygems'
require 'httparty'
require 'json/pure'
require 'find'
 
class CouchHack
  include HTTParty
  base_uri 'http://127.0.0.1:5984'
  format :json
 
  def update( path, document )
    options = { :body => JSON.generate(document) }
    puts self.class.put(path, options )
  end
 
  def get(path)
    self.class.get(path)
  end
 
  def create(db_path, document )
    options = { :body => JSON.generate(document) }
    self.class.post(db_path, options )
  end
 
  def define_view(db_path, design_doc_name, views )
    document = { "views" => views }
    options = { :body => JSON.generate(document) }
    self.class.put("#{db_path}/_design/#{design_doc_name}", options)
  end
end

Once that’s in place you can use the CouchHack class by defining a view like so:

ch = CouchHack.new
gem_views = {
  "small_gems" =>
    {
      "map" => "function(doc) { if (doc.length < 3000) emit(doc.path, doc) }",
    },
  "large_gems" =>
    {
      "map" => "function(doc) { if (doc.length > 3000) emit(doc.path, doc) }",
    }
}
ch.define_view("/railscamp", "gems", gem_views)

This design document, as is its known in CouchDB parleance, defines two views (think ‘baked queries’), to return a list of small gems – those less than 3000 bytes – and a list of large gems – those larger than 3000 bytes.

So where do these gems come from and how do they end up in CouchDB ? That’s what the next and last little fragment of Ruby code does.

Find.find('/Library/Ruby/Gems/1.8/gems/' ) do |f|
  if File.file?(f) and f.ends_with?('.rb' )
    begin
      gem_contents = IO.read(f)
      gem_document = { "path" => f, "length" => gem_contents.length, "content" => gem_contents }
      ch.create( "/railscamp", gem_document )
    rescue Exception => bang
      puts "Skipping #{f}"
    end
  end
end

So what happens is that the last little fragment traverses the filesystem starting at /Library/Ruby/Gems/1.8/gems/ and looks for *.rb files. When it finds one it POSTs that whole document including the file length to CouchDB, where it becomes part of the resultset of one of the pre-defined views. These views can be accessed through the following two URLs (assuming the ‘railscamp’ DB was used).

Feel free to post comments and ask questions.

Enjoy.

P.S. and if you get a chance to go to a *camp conference, GO! They’re an amazing format and you’ll learn soooo much!.

Den Of Ubiquity » apache

Barbler: Integrating JRuby Warbler into Apache Builder

CouchDB Presentation at Railscamp UK