Implementing Hudson Server

By Chris L Hardin
Sr. Software Architect

Hudson is without a doubt the best tool I have used this year in my projects. Continous integration is very important in an Agile development environment, but it most often involves developers committing time and effort into making it happen and it’s a consistent effort that never seems to end. Hudson and Cruise Control are two solutions that change all that.

Let me preface this by saying that I started out using Cruise Control for a month and I then I tried Hudson and in just a few hours, I had removed Cruise Control and I never looked back. Cruise Control has it’s merits but Hudson has all the same functionality plus much much more. I highly recommend the migration if you are still stuck with Cruise Control.

Hudson is a Java project that you can deploy standalone or in a web container like Tomcat. It supports building multiple types of projects and tasks and it has a few hundred plugins to customize its functionality. Hudson is a great tool out of the box, but once you browse and install a few plugins, it really comes into it’s own.

I spent 5 minutes installing Hudson into Tomcat and then I created a new project through the interface. In the configuration, you can tell Hudson where your project is, SVN, CVS, etc. You set how you build your project, whether it is Maven or Ant and then you are off. Hudson has no limits to the configuration options. You can configure it to poll your version control periodically to look for changes, or build every so often or you can build on demand only. You can configure the project to automatically deploy to a container, publish to a repository and archive your builds.

In a project where I used Hudson, I set a series of projects to build periodically by polling SVN and if there was a change, it would trigger a chain of projects to build to create the final project and deploy the enterprise to a container.

Hudson requires a dedicated server. You don’t really want to run this on your desktop. My recommendation is take a decent Linux machine and dedicate it to running your builds and give it plenty of disk space to archive your builds.

Hudson also integrates with tools such as Polarion, ViewCVS and WebSVN to give you reports and link back from changes to see the source. It also will aggregate reports from several sources including Junit reports, TestNG reports, Checkstyle reports, Crap4j and more. Again this is where the plugins are key.

Hudson is easy to maintain and upgrade. Just make sure your HUDSON_HOME environment variable is set to a location where you want all the work to happen and make sure that location is redundant. Don’t store anything under the hudson directory that gets created when the container starts. To upgrade, just simple replace the hudson directory and war file and start your container and that’s it.

Installing a plugin is as simple as going to the plugin page of the Hudson management screen and choosing the plugins you want and download. It will also let you know when there is a new version of an installed plugin.

Hudson will also cluster together multiple machines and allow you to control them from a single instance. You just add machines as slaves by running the slave.jar on the machines you want to cluster and tell the master Hudson instance where these are. When builds run, Hudson will utilize resources on the other machines to accomplish builds as well as the master machine. This functionality isn’t as useful if you have projects that depend on each other. I recommend avoiding having projects depending on others if you can but this is often impossible since all projects should inherit from a set of common framework projects in an enterprise to avoid code duplication and promote reuse.

Hudson has a robust email and notification mechanism with keeping up with build statuses. You can configure emails to be sent to a group on success, emails to be sent to developers who are the culprit behind a failing build and you can even configure options such as Twitter and Calendar updates at the end of a build. There is no shortfall of notifications and events in the system.

The server also had a very pleasing interface. It’s very professional looking and has quite a few Ajax-enabled components.

This tool definitely has it all and the best part is that a trained monkey could configure it. Also, once you get your projects running in it, which doesn’t take long, you can be hands off and coding while Hudson is taking care of your developer and QA builds. You can eve setup deployments to automate your production deployments and set permissions for users to set who can and cannot do certain tasks.

There really isn’t a point if asking if Hudson supports a certain configuration because there is always a plugin to accomplish the task at hand if the out of the box configuration won’t do it. Hudson will save you time, many and make a better software product in the process. You can’t lose. What are you waiting for? Download Hudson today.

Building a project with Apache Ivy

I really love Maven, but sometimes building a Java project isn’t easy when the project and it’s ant scripts have been around for a while. Converting to Maven is not an easy task in this case, but Ivy makes this really simple…once you figure out how to use it.

Just in case you need to be sold on the benefits of using Ivy, here are some key reasons.

1. With Ivy it is no longer necessary to store jars in version control.
2. With Ivy you can upgrade a jarby simply changing the xml
3. Ivy can manage which jars are included and excluded in a war or ear file
4. Ivy can utilize any Maven repository for building

Need I go on…

Ivy is a dependency management library that integrates with Ant. It supports Ivy repositories and Maven repositories. All you need to get started is the Ivy jar in your ANT_HOME/lib, an ivy.xml and a few lines in your build.xml. Lets take a look at an ivy.xml first.

<ivy-module version="2.0"

default” />


default” name=”my-common” org=”my” rev=”2.0-SNAPSHOT” transitive=”false”>

The ivy.xml is pretty straightforward. This one contains many different examples. Ivy is very flexible. The example if for bulding and publishing a war, but you can remove all the configuration options from the dependencies if you are building a single jar.

Now we need the build.xml. This is a bit overkill, but it has all the options you’ll need. The ivy:cachepath tag allows you to build your classpath from your Ivy cache as opposed to copying jars to a local directory and building from there. You only need to call ivy:retrieve in the event that you need to copy jars into the WEB-INF/lib like in the example below. In a jar project, you won’t call retrieve at all. ivy:resolve will determine the location of all dependencies in the ivy.xml and download them to the cache if they are not already there. The publish will copy a finished product to your local ivy repository.

<project xmlns:ivy="antlib:org.apache.ivy.ant"

retrieve dependencies with ivy”>

<ivy:publish pubrevision="${version}"
resolver=”local” forcedeliver=”true”
update=”true” overwrite=”true” publishivy=”true” status=”integration” >

Again, here we see Ivy is extremely flexible. In this example, we also specify an ivysettings.xml file. I highly recommend that you create a Maven and Ivy repository in your enterprise somewhere and manage it with Nexus Dependency management server and point your ivy settings file to that Nexus server. If you choose this path, here is an example ivysettings.xml to get your started. In this example, the internal repositories are first in the chain and then public repositories follow. If you use a custom settings file, put it on a Web server somewhere so that everyone will have access to it.

Another useful trick when using Ivy is to use the Eclipse Ivy plugin to allow Eclipse to build and run using the Ivy.xml. Using the Ivy plugin isn’t simple, but it once you figure it out, you’ll wonder how you ever lived without it. You might even prefer Ivy over Maven for the enhanced flexibility it adds to an existing Ant project.

Scripted behavioral testing with EasyB

By Chris L Hardin
Sr. Software Architect

When I first looked at EasyB, I couldn’t figure out exactly what it was doing or what I could use it for, but after thinking on it a few days, I had one of those eureka moments.

EasyB is a framework to facilitate Behavior Driven Development. It is a compliment to Test Driven Development and not a replacement, so don’t consider it to replace your unit testing because that is not what it is far.

Behavioral testing is used to test smaller units of code grouped together to form a scenario. Think of it this way, you would write a unit test to test creating an account, but you might write a behavioral test looking up an account, creating it if it doesn’t exist and modifying the account all in the same scenario. I typically mimc behaviorial testing by writing a higher level unit tests that does multiple actions. For example, unit testing at the controller level will sometimes mimic the behavioral test since it often represents a scenario, but not always. Also, developing a unit test that builds a scenario breaks the “unit” paradigm anyway. EasyB solves this hole in my testing repertoire.

EasyB is a simple way to facilitate your behavioral testing. It provides a way for you to define a test in Groovy using basic scenarios and storys that even a novice looking at it would understand. Let’s look at an example straight from the easyB web site.

import org.easyb.bdd.stack.Stack

scenario "null is pushed onto empty stack", {
given "an empty stack",{
stack = new Stack()

when "null is pushed", {
pushnull = {

then "an exception should be thrown", {

and "then the stack should still be empty", {
stack.empty.shouldBe true

Pretty self explanatory the scenario being tested here. The English text is anything you want to make up to help others understand what is being tested. You don’t have to use the word test because this is a more conversational convention. Just think of explaining how a scenario to someone else. You rarely would ever interject the concept of testing a step in a scenario.

EasyB gives you a template that you can use to define a shell and then you can go back and fill in the implementation later. Logically, the scenario should come before the code is written anyway. Think of it like testing a Use Case. Unit tests don’t tests use cases like some folks think, but behavioral tests do.

scenario "customers should receive discounts", {
given "a shopping cart with 3 items"
when "a user checks out"
then "they should receive a 10% discount"

Easyb allows you to print out the stories to the command line as the tests run as well. This could come in handy when developing a report for a business analyst to read. The detailed report of your stories can be outputted to a file as well.

Ant, Maven and IntelliJ have great support for EasyB, but Eclipse support is sketchy with the easyB plugin. I tried it and it only really worked with a new project. I could get the existing project conversion to a Groovy project to work.

Running EasyB stories

Command Line:

c:>java org.easyb.BehaviorRunner my/path/to/MyStory.groovy
c:>java org.easyb.BehaviorRunner my/path/to/MyStory.groovy my/path/to/MySecondStory.groovy







Overall, I recommend using easyB for your project if you are using unit tests already. If you’re not a fan of unit testing, and I know many developers that aren’t, you may want to just ignore it all together.

I will give some parting advice ragarding unit testing and behavioral testing. I switched to unit testing several years ago and I never looked back. I immediately noticed that I developed faster, less buggy, more concise code. I no longer have these monolithic methods in my code. i can develop a solution faster than developers who don’t unit test because I have my code written, unit tested and debugged while other developers are waiting for their application server to come up. I only launch an app server now to look at my interface. Here are the benefits of Test Driven Development and Behavioral Driven Development in a nutshell.

1. Less Complex code
2. Fewer bugs make it to QA and to the end user
3. More object oriented code. (this is a side effect of the testing thought process because you think more about writing your code to accomodate testing)
4. Tests are tied to use cases, scenarios and logic units developed from the requirements.
5. Automated regression testing (once the test is written, don’t worry)
6. Automated database seeding for testing.
7. Code metrics on performance are easier to process
8. You will reduce the time you spend debugging (I rarely launch the debugging mode in my IDE anymore.)