Version 1.3.1 is a minor release that bumped the dependent version of Hudson up to 1.347 (was previously 1.319). The plugin should still work on the same Hudson versions that it did before. This change was primarily made so that the NAnt plugin could support new POM features inherited from the Hudson parent POM.
I just recently became a user of the Hudson continuous integration system. Immediately, I noticed how intuitive it was to use, and how easy the UI makes configuring and running builds. Currently, I’m doing primarily .NET projects, and am using NAnt for my project builds. One of the first things I noticed was that the NAnt plugin for Hudson didn’t support passing properties to a NAnt build. My builds tend to rely on properties for defining things like the build configuration or the deployment environment.
Last week, I decided I’d try my hand at updating the plugin, and was able to release version 1.3. Version 1.3 allows properties to be passed to the Ant build and also addresses an issue related to the execution of the NAnt executable on Windows that caused some command line arguments to improperly cause the command to fail. You can find more information on the plugin here.
More releases will be coming in the near future. The next release will target fixing bugs related to executing NAnt on a non-Windows environment (Linux, Mac, etc).
In my limited experience with COM, I have noticed that there is almost nothing written about TDD in relation to COM. Granted, it is an older technology that was developed primarily before agile development and TDD methodologies were widely accepted, but development of COM objects is interface based, which lends itself to mocking. Knowing that much, I figured it shouldn’t be any more work to create mocks of COM interfaces than it would be to mock any other C++ interface (purely abstract class). Once I stumbled upon GoogleMock, this seemed to be a perfectly sufficient tool to get the job done (which it was). After all, a COM interface is just a collection of abstract methods in the same way that a typical C++ pure abstract class is. Why should creating a mock object for a COM interface be any different or more difficult? It turns out that my initial thoughts were completely wrong.