Stephen Connolly stephenc

Here’s my step by step:

1. Install CentOS 5.2

2. Configure Network and Proxies as needed

   I usually create a login script:

   /etc/profile.d/login.sh as follows:

   function set_proxies() { 
   	 local s 
   	 PROXY_ADDR="http://proxy.example.com:8000/" 
   	 for s in HTTP HTTPS FTP GOPHER NEWSPOST NEWSREPLY\
   	          NEWS NNTP SNEWSPOST SNEWSREPLY SNEWS\
   	          WAIS FINGER CSO; do
   	     export ${s}_PROXY=${PROXY_ADDR}
   	 done
   	 for s in http https ftp; do
   	     export ${s}_proxy=${PROXY_ADDR} 
   	 done
   }
   
   set_proxies
   

3. I installed from the DVD, so yum update to ensure everything is up-to-date.

Here is my version of the holy grail, i.e.

Authentication for Apache HTTPD against Active Directory.

This is not the only way to skin this cat, for example you could also use Sander Marechal’s technique (which uses mod_authnz_ldap). However, my problem with Sander’s technique is that you need to have an account in Active Directory which you will use to bind to the LDAP server. That means that the accound password has to be stored in a plain-text file on the Apache server, and if the password expires everything breaks until you go fix the password.

One of my co-workers has asked me to post this up. It’s rough and ready, so make of it what you want.

First off, Acer recently pushed an update for better performance with the Huawei USB modems… I’m assuming that you have this update… check if the file /etc/udev/rules.d/10-Huawei-Datacard.rules exists.

If that file exists then when you plug in a E169g it will be correctly autodetected without requiring poking about with usbmodeswitch… it will bind the three serial ports of the E169G to /dev/HuaweiMobile-0, /dev/HuaweiMobile-1 and /dev/HuaweiMobile-2.

Life gets in the way… but we’re back with our final installment! So where to start, let’s start with a publisher for freestyle builds, then we’ll add a publisher for Maven 2 builds… These will both require some reports to display results, and then finally we’ll need the plugin entry point. But before we get into all that, perhaps I should briefly explain structured form submission support

DataBoundConstructors

Hudson uses Stapler as it’s web framework. One of the things that Stapler provides is support for constructing objects from a JSON data model. Basically, if you have a class with a public constructor annotated with @DataBoundConstructor, Stapler will bind fields from a JSON object by matching the field name to the constructor parameter name. If a parameter also has a @DataBoundConstructor, then Stapler will recurse to construct this child object from the child JSON object.

Over on the Maven2 Users list a recent poster asked what CI server was best, and Hudson was the only answer.

Then Jason van Zyl posted this praise for Hudson:

I know from my vantage point Hudson is the only system I will provide commercial support for at Sonatype because the battle is over. Hudson won by making developers lives’ easier. Kohsuke will go to no end to make things easier for users.

In some ways parsing the JavaNCSS results is the least interesting part of developing a Hudson plugin, as once I have implemented the parser, it is available for everyone. For that reason I will focus more on:

• best practice techniques for parsing results

• common gotchas

• designing for extension

Getting started

First off, we need to analyse the results file format. In the case of JavaNCSS there are multiple ways that the results file can be generated: from the JavaNCSS program directly, from ANT or from Maven. This leads us onto gotcha #1

Ok, life has got in the way and I have not been able to update this series as quickly as I originally intended. In any case, there were a number of bugs in Hudson that I discovered and are now fixed, and there was a good deal of tidy-up needed in order for me to figure out what to do for parts 6 and 7. The good news is that I am getting closer to finishing writing these final two parts. The bad news is that there are a number of corrections to the previous posts (I have put some corrections in-line for parts 4 and 5). This post aims to ensure that, for parts 6 and 7, everyone is able to follow from the same code!

Until now we have been generating classes that collect the results we want to display. We have not hooked into Hudson’s methods of displaying reports. There are essentially four places that we could want to generate reports:

• In each individual build (we’ll call this a Single Build Report),
• In the project (we’ll call this a Single Project Report),
• In the summary of all the Maven 2 module builds associated with a multi-module Maven 2 build (we’ll call this an Aggregate Build Report), and finally
• In the Maven 2 project itself (we’ll call this an Aggregate Project Report).

To make matters more confusing, each of these reports usually to implement different classes and need to implement different interfaces:

This is the fourth installment, which covers the two abstract classes that call the Ghostwriter for us. When we implement our plugin we will extend from these two classes. These classes perform the work of calling the Ghostwriter at the appropriate points in the build, the concrete classes that we will develop in Part 5, however have the responsibility of creating a configured Ghostwriter and providing it to the superclass for execution.

In this, the third installment, I will introduce some helper classes that we can use to let Publisher and MavenReporter subcontract the job of creating the build reports. Firstly, we have the Ghostwriter interface. An implementation of a Ghostwriter is the work-horse that writes the build report. Secondly, we have the BuildProxy class. This class is a more general MavenBuildProxy that works for both Maven builds and non-Maven builds. In part 4 we will tie these helpers into the Hudson plugin framework with an AbstractMavenReporterImpl and AbstractPublisherImpl from which we can extend our plugin’s MavenReporter and Publisher.