Ruby script to install JFace JARs into your local Maven repository

After figuring out how to use Maven to write SWT applications, I figured it was time to tackle JFace.

If you read through the JFace wiki page above, though, it says that to use JFace + SWT outside of Eclipse we basically have to locate several dependencies, namely:

• org.eclipse.core.commands_<version info>.jar
• org.eclipse.equinox.common_<version info>.jar
• org.eclipse.jface_<version info>.jar
• org.eclipse.osgi_<version info>.jar
• org.eclipse.ui.workbench_<version info>.jar

All of these are available in the standard installation of Eclipse IDE in the ${ECLIPSE_HOME}/plugins directory.

Now, it would be a 10 minute job to manually search for, copy and paste the actual JAR filenames and execute the Maven commands to install those into the local repository with proper group and artifact ids.

Since I’m ‘lazy’, though, instead of 10 minutes I decided to spend a couple of hours writing a Ruby script to do this all for me (I originally started to write it in bash but I realized it’d be a lot easier in Ruby).

Here it is.

Using the Subversion Ruby Bindings

I work with a distributed team of Ruby (on Rails) developers, and we use Subversion as our repository of choice. Just recently, I wanted to find out which files were recently changed or added to a particular directory of our project.

Doing it manually would’ve been tedious. I also wanted to do it with code so that maybe sometime in the future we might be able to script some behavior depending on the last changed date of a file or group of files in our repository.

I could’ve resorted to merely calling svn info and parsing its output, but I thought maybe this was a good excuse to sharpen my Ruby chops and figure out the Subversion Ruby bindings.

Using Rails console to copy records across databases

If you’re developing with Rails using PostgreSQL as your database back-end, you might find yourself in the same situation I was just in.

Rails, by convention, makes us think in terms of application ‘environments’: development, test and production (where I work we add “staging”). Each environment is given it’s own database (each environment can even have entirely different database servers).

During development, there’ll be times where you start populating a table with meaningful data as you develop and test. For example, you might have created a users table and added a couple of logins.

In some cases, data that’s meaningful in development can also be meaningful during staging or production. So, like me, one day you might find yourself wanting to copy some rows or an entire table from one database to another.

If I were using MySQL, I could easily do this via the SQL console. But PostgreSQL doesn’t support cross-database references (offering schemas, instead).

Fortunately, Rails comes with a nifty console which can do the job for us!

Bootstrapping your Database with Ordered Fixtures

Ruby on Rails provides a convenient way to ensure consistent database state for all unit tests and this is accomplished through Fixtures.

In the Rails Weenie forums technoweenie presented a technique that allows us to ‘bootstrap’ our development or production database using the same underlying mechanisms.

The way it works is first we place YAML files similar to the ones we use for testing under db/bootstrap (instead of test/fixtures). Then it’s a simple matter of executing:

rake db:bootstrap:load

Fixtures and Referential Integrity

The only problem with the above technique is when your tables have foreign key constraints (as they easily could if you use ActiveRecord Migrations with my own Migrations Constraints Plug-in).

When using fixtures for unit tests, we can explicitly specify the order of the fixtures in code. For example:

fixtures :foo, :bar_references_foo

The original technique by technoweenie allows us to specify a fixture order by an environment variable:

FIXTURES="foo bar_references_foo" rake db:bootstrap:load

While it works, it requires us to specify our fixture names and their order every time – not very DRY if you ask me.

Ordered Fixtures

Sandro Paganotti on RailsOnWave.com also realized this and presented his own version of rake db:bootstrap:load that attempts to address this.

The idea is to let us number our fixtures, similar to how we number our migrations, so that they can be loaded/unloaded in proper order according to our foreign key constraints.

Except, when I looked more closely at his code, I had my reservations.

First, and most glaring, is that he sorts the fixtures array, even if it’s passed in through the FIXTURES environment variable. I think this totally defeats the purpose of explicitly specifying the fixtures that way.

Second, and relatively minor, is that he hard-codes the format of the fixture file names so they have to be 2 digit numbers followed by an underscore, then the table name.

My rake db:bootstrap:load

So I set about to write my own, slightly more evolved version of Sandro Paganotti’s rake task.

element.in set

There’s something about Ruby

What continually excites and amazes me about Ruby is how expressive it is, how extensible it is, and how elegant it is.

Because you can extend any class/object in Ruby, and because everything is an object, you can essentially refine or redefine the language and its idioms to suit your thinking or preferred way of expression.

Case in point – if you deal with collections, ranges or subclasses you will have used one of the the following expressions (Ruby in Java-esque style):

x >= 0 && x < n
obj.kind_of? SubClassA || obj.kind_of? ClassB
some_range.include? -1
some_hash.keys.include? "ABC"
symbol_array.include? :a_symbol

Here are the same expressions using a more Ruby-like idiom:

(0...n).include? x
[SubClassA, SubClassB].include? obj.class
some_range.include? -1
some_hash.include? "ABC" # Hash.include? is an alias for has_key?
symbol_array.include? :a_symbol

Certainly more succinct than the first set of expressions, but are they really more expressive?

In particular, the [SubClassA, SubClassB].include? obj.class to me just sounds, well…funny.

All of the above more or less translates to “does set S include element E?“. Maybe it’s just me, but in my mind it’s just more intuitive to rephrase that question as “is E part of S?”

What I want is to be able to call some method on any object asking it whether it’s part of some collection or range.

Fortunately, it’s a cinch to ‘hack’ this into Ruby so I can use it any time I need or feel like it, and that’s what I’m about to do.