Copland is an Inversion of Control (IoC) container, written in Ruby, for use in Ruby programs. Depending on whether or not the term “IoC” means anything at all to you, you can read either the next section (“Copland sans Buzzwords”), or the one after it (“Copland avec Buzzwords”).

Copland sans Buzzwords

Imagine being able to take all the various pieces of your program and implement them in a vacuum. You just assume that all dependencies will be satisfied at runtime, by properties being set, or parameters being passed to each object’s constructor. Nowhere in your code do you specify the instantiation of another application component.

However, those dependencies and relationships between objects still exist; you’ve just written your code without any explicit knowledge of them. Somehow, you still need to be able to wire the pieces all together so they work as required in tandem. To put it another way, you need to be able to take your classes and compose them into something greater.

Enter Copland.

Copland helps you tie the pieces of your application together. Instead of inter-object relationships and dependencies being specified in the code, you feed them into Copland. This makes those relationships easier to modify, since you never have to modify the source code to change them.

Copland is named after the American composer Aaron Copland for a reason. You may or may not have any musical talent, but Copland will give you the ability to compose great “symphonies of software” by allowing you to work easily at both extremes of software architecture:

1. It helps you to focus on the implementation of a single class by allowing you to ignore the implementation details of the dependencies of the current class.
2. It helps you to focus on the relationships between classes by allowing you to specify those relationships and dependencies as run-time configuration options.

Copland avec Buzzwords

If you are already familiar with IoC, then you either love it or hate it. In the first case, you probably only want to know what features Copland has compared to other IoC containers you’ve used. In the second case, there’s probably not much I can say to change your opinion, so I won’t try.

I’ll save all the meaty discussions for the chapter on Copland’s design, but here’s the rundown:

• Copland is based heavily on the HiveMind IoC container for Java. If you’ve ever used that one, much of Copland will probably feel very familiar to you.
• Copland allows you to define service points, configuration points, contribute to configuration points, add interceptors to services, add listeners to services, define multicast services, and even make your services web-enabled by using the built-in SOAP or dRuby interfaces.
• Copland uses YAML for its configuration files, instead of XML. If you’ve never used YAML, you’ll find it surprisingly easy to pick up.

The Buzzwords Themselves

As Martin Fowler points out, the term “Inversion of Control” is a poorly-chosen one. Still, it is the one that most people know the concept by, so I’ll use it throughout this document.

For more info about IoC, you might try reading the following articles:

• Inversion of Control Containers and the Dependency Injection pattern (Martin Fowler)
• Inversion of Control (from the PicoContainer site, another Java-based IoC container)
• Inversion of Control (HiveMind’s take on the subject)

Currently, Copland features the following buzzwords:

• Type 2 IoC (setter injection)
• Type 3 IoC (constructor injection)
• YAML-based descriptor configuration
• Object-, Class-, and Singleton-backed services
• Service factories, with extendable rule-processing engine for defining new factories.
• Interceptors (for adding basic AOP-like “pre” and “post” hooks to every method of a service)
• Multicast services, which do nothing themselves except delegate recieved messages to a set of other interested services.
• Event/Listener infrastructure, for notifying services at various points during another service’s lifecycle.
• dRuby and SOAP support, in the form of two core services that applications may use to export their services to remote clients.

Using RubyGems

Installing via the RubyGems system is trivial—you just need to make sure that you have RubyGems properly installed. Once RubyGems is installed, make sure you are logged in as a user with permissions to update your local gem repository, and then type:

  gem install copland

Alternatively, you can download the gem file itself (if, for instance, the RubyGems gem repository is down, or hasn’t been updated with the latest version of Copland). Just go to Copland’s RubyForge project page and download the gem for the latest version. Then, from the command-line, type:

  gem install path/to/the/file/you/downloaded.gem --local

Manual Installation

If, for whatever reason, RubyGems is not an option for you, you can go to Copland’s RubyForge project page and download the tar.gz file for the latest version of Copland. Then:

1. Unpack the archive. It will extract all files to a new directory under the current directory.
2. cd to the new directory.
3. Make sure you are logged in as a user with permissions to install Ruby libraries. If you are, just type:

  ruby setup.rb config
  ruby setup.rb setup
  ruby setup.rb install

Copland is currently distrubuted under the BSD license. Versions of Copland prior to 0.6 were released under the same license as Ruby.

This manual (both in YAML and HTML formats), as well as the minimal Ruby scripts used to generate it, are distributed under the Creative Commons Attribution-ShareAlike license.

Mailing lists, bug trackers, feature requests, and public forums are available (courtesy of RubyForge) at Copland’s RubyForge project page. Just direct your browser to http://rubyforge.org/projects/copland.