Maven, Amazon EC2 and SpringSource Cloud Foundry

You may have heard about the just announced SpringSource Cloud Foundry and how it is based on the CloudTools project, that includes a Maven plugin to deploy Java EE applications to Amazon EC2, starting the images as part of the build process.

Some time ago I started another Maven plugin, the Amazon EC2 Maven plugin, which allows you to start and stop EC2 AMIs as part of your build process. Unlike CloudTools, it’s a lower level plugin that can start any AMI, a very different goal.

My use case? starting Selenium Grid Remote Control images for different environments and browsers before the integration tests start, wait for the images to be online, run the integration tests, and shutdown the images. Check my previous Enterprise Build and Test in the Cloud entry for more details.

You could also have your AMIs with your webserver, db,… pre-installed, start it, deploy using the Maven Cargo plugin to any container of your choice, and shutdown the image at the end of the tests.

The plugin allows all the configuration options than the EC2 API does, because it’s based on the Typica EC2 library. Start any number of images, associate elastic IPs, choose availability zones,…

Hope you find it useful.

Using Subversion Ruby bindings

I tried to do some subversion hacking from Ruby, very simple things like add/remove files,
commits and so, and realized that there’s no documentation at all out there, just blog posts
here and there.

I finally got something working, including user authentication (that is not as easy as you would
expect) and ignoring https certificates not signed by a trusted CA. Something like committing a file is not as simple as it would seem.

You have to make sure you have the latest version installed. In linux it means installing the subversion-ruby package. In OS X is more complicated, you need to remove the preinstalled subversion, install the newer one from Collabnet, and move some files around.

mv /Library/Ruby/Site/1.8/svn /Library/Ruby/Site/1.8/svn.bak
mv /Library/Ruby/Site/1.8/universal-darwin9.0/svn /Library/Ruby/Site/1.8/universal-darwin9.0/svn.bak
ln -s /opt/subversion/lib/svn-ruby/svn /Library/Ruby/Site/1.8/svn
ln -s /opt/subversion/lib/svn-ruby/universal-darwin/svn /Library/Ruby/Site/1.8/universal-darwin9.0/svn

Once you have it installed then you can call the svn libraries

  require "svn/core"
  require "svn/client"
  require "svn/wc"
  require "svn/repos"

  make_context("") do |ctx|
    # checkout
    ctx.checkout SVN_URL, "/tmp"

  # Add a file and commit with a message
  make_context("Adding a file") do |ctx|
    ctx.add f
    ctx.commit f

  # from
  def make_context(log)
    ctx =

    # Function for commit messages
    ctx.set_log_msg_func do |items|
      [true, log]

    # don't fail on non CA signed ssl server

    # username and password
    ctx.add_simple_prompt_provider(0) do |cred, realm, username, may_save|
      cred.username = "myusername"
      cred.password = "mypassword"
      cred.may_save = false
    # setup_auth_baton(ctx.auth_baton)
    return ctx unless block_given?
      yield ctx

Playing with Ruby and Rails

I have been playing with Ruby and Rails for a good number of months already and fond it quite interesting.
It’s fairly easy to start new projects and get going, although it’s also very easy to make
mistakes if you don’t know what’s going on behind the scenes. For instance, it’s very easy
to have the N+1 SQL problem, or dependency mismatches between machines.

What I like:

  • Migrations
  • Different environments (dev, test, production), and predefined configurations for each, like log level
  • Real time development, change a file and see the changes immediately.
  • AJAX support, very easy to create partial updates and requests

What I don’t like:

  • Dependency management, if you don’t define versions it will take whatever is installed in the system
    (but probably I’m just spoiled by using Maven for so long)
  • Debugging, it ends being puts statements, although there’s probably something helpful out there
  • The plugin ecosystem, it’s a big mess with plugins and forks of plugins, and forks of forks,… It’s too easy to fork, which makes users less likely to contribute the changes and just work on their version.
  • Scripting, mistakes like typos are very easy to do, and refactoring becomes a big PITA