Testability Explorer Plugin for Hudson

Yesterday I finished my first plugin for the continuous integration engine Hudson. Hudson is the engine of choice at our Bwin office in Stockholm. The idea to write a plugin was born while attending a presentation about an open source tool called Testability Explorer at OOPSLA, presented by Misko Hevery from Google.

Writing the Hudson plugin took me almost two months now. There is not so much documentation about plugin creation on the web. I started off by reading through a great tutorial I have found here. This is almost the only documentation I could find. But even with this 7-part tutorial you will still have to do a lot of try-and-error coding. In the tutorial you will learn about Publishers, Reporters and Reporting. But a lot of stuff is not covered. The best approach for new beginners is to read the tutorial and set up your own base code structure accordingly. Then check out all the other existing Hudson plugins and check how other developers solve the same tasks that you will have to accomplish. Luckily for me, one of the busiest plugin developers spoke German, so I could bug him with some personal questions via Email and he helped me out a lot.

In Hudson you can have Freestyle and Maven 2 based projects. Your plugin should support both project types. Unfortunately both project types require different entry points. For Freestyle projects you start by writing a class that derives from the Publisher class. Maven 2 projects require you to write a Reporter class. From there, a big challenge will be to write code that can be re-used for both project types. This is not always easy, as you have to subtype different Interfaces and Classes for Maven 2 and Freestyle projects.

Hudson is using Stapler for rending web output. I have never seen this framework before, so this is another technology you will have to familiarize yourself with when writing a plugin. Hudson is build so that certain methods will be invoked via Stapler on your classes. It was frustrating for me to find out, how these methods had to be called and what signatures were required to put everything to work. For instance, in one of the report classes (AbstractBuildReport) I had to have a method called getDynamic that returned an Object. This Object could be anything that I wanted to visualize in my report details. I found out about this method inly by looking at other plugins, it was neither documented in the tutorial nor somewhere else.

Another black box for me is the Master and Slave thing, that is mentioned in the Tutorial. It was said that some code runs in the Master thread, which is apparently the main thread that Hudson executes in. In my plugin I create a second thread that will parse the Testability Explorer reports. This is according to the tutorial. However, I never had to copy any files back to the Master. Everything worked without that, so I have no clue why this would be needed. The plugin works and I am happy about it. However, I still have this unsatisfying feeling that I did not understand everything correctly and dont know anything about the Hudson internals.

So for those of you planning to write their first Hudson plugin, do not expect so much fun for the first try. Probably a lot of code written in the Testability Explorer plugin I would do differently now, but maybe that is just normal in software development.