Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

Measuring code quality with Sonar
By Allard Buijze, 26 February 2010

“At JTeam, we continuously strive for good quality code. The reason is very simple: bad quality code slows down the development process. The small investment pays out in even the simplest of projects.”

Sonar: a valuable tool for every Java shop
By Hans Westerbeek, 22 February 2010

“If your organization develops Java applications, chances are that Sonar could be very valuable for you. Sonar helps you calculate your technical debt by analyzing your project’s source code.”

Getting More Agile – 2009 in Review
By Thomas Ferris Nicolaisen, 21 February 2010

“With our mavenization efforts, we were recently able to make use of Sonar (which rocks, btw) instead of the old, more primitive (boring) Ant reports in Hudson.”

A Sonar Cobol Plugin
By SonarSource, 18 February 2010

Coming soon… “SonarSource has developed its own Cobol parser and packaged it in a Sonar Cobol analyzer. It allows to perform objective and automated Cobol code quality and standards reviews against pre-defined rule sets and coding best practices. It also generates standard code metrics like number of lines or density of comments”

Add code quality metrics to your GateIn Dashboard with Sonar
By Jeremi Joslin, 11 February 2010

“Sonar is an open source platform to manage code quality. It enables to collect, analyze and report metrics on source code. At eXo Platform, we use Sonar to manage and monitor the quality of our codebase.”

Sonar Integration for AnthillPro
By Eric Minick, 10 February 2010

“A Sonar plugin for AnthillPro is now available through Urbancode’s Supportal (support portal).”

Sonar SCM Activity Plugin version 0.1
By Evgeny Mandrikov, 27 January 2010

“People, who follow me on Twitter, already know about new plugin for Sonar developed by me. Meet – Sonar SCM Activity Plugin.”

Java Build Server
By Manuel Küblböck, 23 Januray 2010

“In my last Java project, I set up a build server with Continuous Integration (CI) capability. I am a big fan of Test Driven Development (TDD) and I quite enjoyed Hudson telling us right away when someone checked in code that broke the build. It just gives you so much more confidence in your code and keeps it releasable at all times. In addition, we used Sonar to measure the quality of our code.”

It's been a little over a month since I pinged Kohsuke about an "official Hudson blog"; my role has been nothing more than writer and editor of a community resource, while I have invested a lot of time in Continuous Blog it is not "mine" so much as it is "ours." I feel I have a responsibility as the current maintainer of this resource to be as open as possible about what's going on with CB. When I sat down to write the inaugural post, Welcome to Continuous Blog, I set forth a few goals:

• Help advocate the use of Hudson to the larger internet community
• Be a central source for tutorials and helpful information to Hudson users of all skill-levels
• Recognize the numerous contributors to the Hudson project for their efforts

Being a community resource, I wanted to review our progress on those goals along with some other interesting details about Continuous Blog and my community efforts. My metrics for achieving these goals are largely based on web traffic to this blog and retweets via the @hudsonci twitter account. First a minor overview of some of Continuous Blog's traffic, then I'll get to reviewing the goals.

Visitor trend via Google Analytics

Over the past month Continuous Blog has seen just under 10,000 visits from a number of different sources, the top sources being:

• Feedburner links posted to @hudsonci
• Direct visits
• Feedburner
• Referrals from the "blog" link on hudson-ci.org
• reddit
• Links from the Java.net community portal and associated weblogs

In addition to general web traffic, Continuous Blog has around 350 RSS subscribers.

To put these numbers into perspective, Hudson has seen commits from 173 different developers and the @hudsonci twitter account has about 1,100 followers.

Hudson Advocacy

Looking at the traffic sources and the volume of traffic coming from what I would consider "the wider internet community" I'd say I failed to meet my own expectations. The majority of traffic seems to be coming from "within the community", which is certainly not a bad thing by a stretch, but I was hoping to start to see more visitors who are less likely to be using Hudson already. There are signs of this (I think) in the low number of search referrals, roughly 370 visits. To me this indicates the early age of this site, small number of external links to Continuous Blog and the content isn't "interesting" enough to come up in searches for terms like "continuous integration with python".

The vector for improvement in advocacy, in my opinion, is to focus more on tutorials and user guides in the next month. Mike Rooney's post on Keeping your configuration and data in Subversion was both discussion provoking, but one of the more visited pages over the past month. I'll be reaching out to more power-users from differing backgrounds to try to get some more tutorials on using Hudson for Python, Ruby, and Cocoa development while continuing to bug some of you Maven2 pros about guides.

Central information repository

I feel I failed to meet my own expectations here as well, it has only been a month (feels like an eternity!) so the amount of information we've been able to aggregate is small, but growing.

I have likely spent too much time covering Hudson community news, which I feel is important, to put a human voice in front of commits and releases, but it is not what I originally intended to spend the majority of my time doing.

Recognition of contributors

In my opinion, this goal I've met. When writing up each Hudson release I've made certain to give credit where credit is due, to those that contributed, Through the "spotlight" series of posts I've also made an effort to highlight power-users of Hudson, trying to glean interesting details about their installations from them for our benefit. Unfortunately I've done a poor job highlighting the contributions from individual plugin developers, something I'm still not certain how to correct.

Content

If you've been following the blog you have no doubt noticed the regular occurrence of certain types of posts, these regular series are:

• "This Week in Plugins"
  • This post is halfway script generated, pulling all the release details out of SVN history to help me generate a post. The intention of the post being to cite new or notable plugins, while giving an informative listing of "what's happening" in plugin development for the past week.
• "Spotlight On"
  • The only interview-formatted series I've got going right now, I've been trying to find companies or organizations who are using Hudson in interesting ways and are willing to let "us" peek behind the curtains a bit. This started more from curiosity, but I think it's fun to let Hudson users brag about their set ups.
• Hudson 1.xxx Released
  • Pretty straight-forward reporting on a release of Hudson, depending on the contents of the release there may be some calls to action or editorializing on what's gone into the release.
• Links for
  • Roll-up of links shared or retweeted via the @hudsonci account, uncertain whether this is worth the time spent.

My two questions to the community in general would be:

• Do you dislike any of these?
• What else would you like to see on a regular basis?

I'm certainly open to suggestion, I'd like Continuous Blog to continue to be interesting to the Hudson community and if certain kinds of posts are boring or uninteresting, I can cut them from the line-up.

Challenges

The largest challenge of Continuous Blog is time. As it stands the majority of content I write or edit in some capacity, which is a larger amount of time than I expected to spend. All said and done it takes me between 6-10 hours a week to write for CB, keep tabs on @hudsonci and peruse the mailing list for interesting things. This probably isn't maintainable, and if for some reason a bus hits me (not uncommon around here), this blog would go dark for a while.

This can be easily fixed by simply adding more contributors to the blog, I'll post more on how to write for Continuous Blog in another post.

All said and done, I am looking forward to another month of writing and following the Hudson community. I'm grateful for all those who've asked questions, been interviewed, wrote content and participated in discussion in the comments. For those of you in the Bay Area, I do hope you come out for the meet-up in mid-March, for the rest of you, I'll catch you on IRC :)

Unit testing asynchronous stuff is tough. This is something I had to live with for the last few days working on one of our products. This is compounded by having to unit test jobs that go through ThreadPool.QueueUserWorkItem() - because it's using the ThreadPool it's hard to synchronize your test. If you just do this:

   1: [Test]

   2: public void TestAsyncStuff()

   3: {

   4:    bool setInBackground = false;

   5:  

   6:    ThreadPool.QueueUserWorkItem(o => {setInBackground = true;});

   7:  

   8:    Assert.IsTrue(setInBackground);

   9: }

Your test will almost always succeed. But then again it just might fail - there's a race condition between the assertion and the background thread on setInBackground. This is of course a hugely simplified case – usually the call to QueueUserWorkItem() is hidden somewhere in the code under test where it does time consuming calculations and not just setting boolean values. These race conditions may cause nastier results than a simple dirty bool, and may be quite hard to debug.

Now, it's our responsibility to synchronize our tests - always make sure everything in the code under test finished running before asserting against it. But how does one synchronize the ThreadPool? We all know how to synchronize a Thread, right? Just .Join() on it and you're good. How about we turn the mighty ThreadPool into a puny Thread using Isolator?

First, we need to refactor the call to ThreadPool.QueueUserWorkItem() to a method we can fake - unfortunately, we can't fake it directly because it's in mscorlib. Let's say we did it like this:

   1: public class ThreadingWrapper

   2: {

   3:    public void QueueAsyncJob(Action<object> job)

   4:    {

   5:       var callback = new WaitCallback(job);

   6:  

   7:       ThreadPool.QueueUserWorkItem(callback);

   8:    }

   9: }

Now, using DoInstead() we turn the call to QueueAsyncJob to a call to a Thread. This way we maintain the asynchronous nature of the code under test, and maintain the capability to synchronize our test without jumping through hoops. For instance:

   1: [Test, Isolated]

   2: public void TestAsynchStuff()

   3: {

   4:    bool setInBackground = false;

   5:    Thread backgroundThread = null;

   6:  

   7:    Isolate.WhenCalled(() => ThreadingWrapper.QueueAsyncJob(null))

   8:       .DoInstead(context => 

   9:                          {

  10:                              var job = context.Parameters[0] as Action<object>;

  11:                              backgroundThread = new Thread(() => job(null));

  12:                              backgroundThread.Start();

  13:                           });

  14:  

  15:    ThreadingWrapper.QueueAsyncJob(o => {setInBackground = true;});

  16:  

  17:    backgroundThread.Join();

  18:  

  19:    Assert.IsTrue(setInBackground); // if we reached this we can be sure the asynchronous code finished running

  20: }

Mission accomplished! Lets do a quick recap – we need to test code that uses ThreadPool.QueueUserWorkIteam(). This is not fun because we can’t easily wait for all worker threads to finish, and it’s hard to synchronize our tests that way. Solution – we switch from using ThreadPool to using a regular Thread! How? extract the call to ThreadPool into a method, and when that method is called, replace its implementation (using the wonderfully flexible DoInstead()) with a simple thread creation and invocation. Before you assert on the test’s result, just call Thread.Join() and you’re good!

Ever wanted to pick the brains of multiple Hudson developers and users, all at the same time? Feel like finally meeting Kohsuke in person? Now's your chance!

We're hosting our second-ever Bay Area Hudson Hackathon/Meetup on March 19th and 20th. That's nearly two whole days of Hudson!

Day One (Mar. 19)

The first day of the hackathon/meetup is aimed primarily at those working with Hudson's core, or are building on top of Hudson (plugins, etc).

• Start: 10 a.m.
• End: 5 p.m.
• Location: Oracle Santa Clara campus in the "library" conference room of SCA7 "Mansion" building.

There will a number of community and corporate Hudson hackers joining us on Friday, so bring everything you'll need to get some grade A hacking done with Kohsuke, Andrew Bayer, Alan Harder and your fellow plugin hackers.

Day Two (Mar. 20)

I'm tentatively calling this the main event, which will be hosted at the delightful Hacker Dojo in Mountain View. The "main event" will carry over the hackathon from the day before at Oracle, into a full blown community hackathon and meet-up. This is for Hudson hackers and users alike!

• Start: 10 a.m.
• End: 6 p.m.
• Location: Hacker Dojo (Savanna room)

As I've pointed out before, Hudson's getting a lot of attention in other developer circles such as the Python, Ruby, Cocoa communities. As such, I'm hoping to get a lot of folks interested in using Hudson to come to Hacker Dojo where we (already being Hudson users) can help get them up to speed with all the great things Hudson can do.

If you're interested please RSVP:

• Via the hackathon page on the wiki
• Via Facebook for day one and day two

How you can help

While I casually refer to myself as a "PR intern" for Kohsuke, I'm technically a busy software engineer, meaning I'm grateful for all the help I can get.

Get the word out

The best way to help get the word out is to talk about Hudson and the meetup, this includes:

• Link to this post on Twitter
• Ping any user groups you are a member of in the area
• Blog about it
• Let your co-workers know about it
• Attend!

Volunteer to help setup/teardown

Hosting the Saturday event at Hacker Dojo does carry some responsibilities with it. We will need some extra hands to make sure everybody has power, refreshments are chilled, lunch is ordered and delivered, and of course, cleaning up after we leave. If you're in a generous mood, or in a real need for some karma, sign up to help on the bottom of the wiki page

I am hoping Oracle and some other heavy users/contributors will kick in a few bucks for lunch and drinks on Saturday, if you think your company can help us out, feel free to ping me directly at tyler at linux.com.

<!--break-->

Last Friday, March 5th, Hudson 1.349 was pushed out into the wild with an even split of bug fixes and enhancements. Included in this release is Alan Harder's (a.k.a mindless) old data monitor code, discussed previously in the post "Call for Testers: The older the better." Included in this release were further updates to the japanese and german localizations of Hudson; if you're interested in helping localize Hudson into more languages you can join the effort via the Internationalization page on the wiki.

Now for the breakdown of the 1.349 release:

Bug fixes

• Fix deserialization problem with fields containing double underscore. (issue 5768)
• Fix deserialization problem for Exception objects where the XML has bad/old data. (issue 5769)
• Fix serialization problem with empty CopyOnWriteMap.Tree. (issue 5776)
• Fixed a bug that can cause 404 in the form validation check.

Enhancements

• Remote build result submission shouldn't hang forever even if Hudson goes down.
• Added a monitor for old or unreadable data in XML files and a manage screen to assist in updating files to the current data format and/or removing unreadable data from plugins that are no longer active. "Manage Hudson" page will show a link if any old/unreadable data was detected.
• Added a mechanism to bundle init.groovy inside the war for OEM. (report)
• Added an extension point to annotate console output. (issue 2137)

Contributors

Hudson 1.349 contains 43 commits from 6 contributors, due to the merging in of Alan Harder's old-data-monitor branch the commit count is a bit off from the amount of code change that actually went out in 1.349.

• abayer
• kohsuke
• mindless
• sogabe
• swiest
• wyukawa

As usual, you can go grab the latest .war file straight from hudson-ci.org or if you're using a native package, use your package manager to upgrade.

<!--break-->

Last week I recorded an interview with “Uncle Bob” Martin of ObjectMentor. We talked about craftsmanship, unit testing and other cool stuff. The video is now in editing, but it will be up this week. Stay tuned…

A little late, but this past week we released 19 plugins including one new release, the Libvirt Slaves.

• Feb 28th

  • Accurev plugin 0.6.10

• Mar 1st

  • Subversion Release Manager plugin 1.1
  • Clover plugin 2.6.3
  • SCTMExecutor 1.5
  • global-build-stats plugin 0.1-alpha3

• Mar 2nd

  • ClearCase UCM Baseline Plug-in 1.4
  • Accurev plugin 0.6.11
  • JIRA plugin 1.20

• Mar 3rd

  • NAnt Plugin 1.4.1
  • Edgewall Trac plugin 1.10
  • NCover plugin 0.3
  • nabaztag 1.7
  • Mozmill Plugin 1.3
  • Mantis plugin 0.9
  • Harvest SCM 0.3
  • Subversion Plug-in 1.12

• Mar 4th

  • Performance Publisher plugin 7.96
  • Artifactory Plugin 1.0.7

• Mar 5th

  • Perforce Plugin 1.0.23

• Mar 6th

  • SCTMExecutor 1.5.1

• Mar 7th

  • Libvirt Slaves plugin 1.0
  • Emma plugin 1.13 <!--break-->

Earlier today we released a new product unto the unsuspecting world – Test Lint is its name.

 

Test Lint (Beta): Find common problems in your unit test code IMAGE

We believe in unit testing and test driven development, and we also know how hard it is to learn to write proper unit tests that are readable, maintainable and trustworthy. That’s why we created Test Lint – the world’s first and only coding advisor for unit tests in visual studio 2010.

What does it do?

Test Lint parses your code as you type it, and looks for common problems in your unit test code – from missing asserts to having tests depend on other tests – Test Lint will notify you on the spot about each possible issue with a visible queue right inside your editor, right next to the link where the issue appears.

The Art of (Good) Unit Testing

Writing unit tests is easy. Writing good unit tests – that are readable, maintainable and trust-worthy is a bit harder if you’ve never done it before. So we took Roy Osherove (author of The art of unit testing) and asked him to write down, based on his massive experience with unit testing, common problems that people do when they first start unit testing. Then we put that knowledge inside a visual studio 2010 extension– it’s like having your own personal coach letting you know of problems as you type them, really.

What issues does it detect?

Currently Test Lint finds a very short but also very common set of problems:

· Missing asserts in your tests

· Multiple asserts \verifications on different objects in the same test

· Tests that invoke other test methods

· Logic inside unit tests (loops, Ifs,Switchs..)

More rules will be added soon, and in upcoming versions, you will even be able to write your own rules based on our parsing infrastructure.

Works with all major frameworks

Test Lint will detect issues in tests written with:

· Microsoft Test Framework

· NUnit

· MbUnit

· XUnit.NET

· CsUnit

Getting Started

To get started with Test Lint:

· Download the latest installation package (in vs 2010 package form)

· Double click on the package to install into visual studio 2010 (RC and upwards)

· If Vs 2010 is already running, you should restart it

· Now that it’s installed and running, just open existing tests code, or start writing new test code.

· Since this is a public beta, we don’t want you to use a non stable version for too long. You’ll be asked to download a new version within 30 days of the first usage.

Later today we will be releasing Typemock Test Lint – a free extension to vs 2010 that helps find common issues with unit test code – such as missing asserts, too many asserts, tests calling other tests and more.

Oh, and you’ll be able to write your own rules for it as well (not just for tests!)

hang on – just an hour or two longer!

 

PS – why is it called Test Lint?

I’ve realized for some time how powerful creation stories are in spreading ideas. Think of an idea that has power in your life or work. Do you know the story of the origin of that idea? If you don’t, does the person who introduced you to the idea? My experience is that I know the story or the person I learned the idea from knows the story. An idea only spreads as far as the story of its creation.

When I’ve had impact on software development, there has always been a story attached:

• The group of us on a hillside in Colorado experiencing patterns first hand
• Erich and I writing JUnit on a plane going to OOPSLA
• The C3 project at Chrysler that spawned Extreme Programming
• The workshop at Snowbird where we (well, actually I was pretty sick and didn’t do any of the work) wrote the Agile Manifesto

I was looking at the landing page of a two-person startup today and having trouble understanding the concept they were promoting. Their prose was obviously carefully crafted, but it was all written with abstract nouns–”we turn conversations into knowledge”. It didn’t make sense to me concretely. I suspected that the product might be applicable to my work but I couldn’t tell for sure.

My suggestion to the team was that they put their creation story on the landing page. If I could read about the moment they had their cool idea, they would have given me two valuable gifts–the emotional energy to keep working at understanding their idea and the beginnings of an intellectual understanding as well. To create their product they needed an epiphany, to be faced with a seemingly insolvable dilemma and for the resolution of that dilemma to come to them. If they told that story and I saw myself in the dilemma they presented, I would be pretty certain I was a good candidate for their product and I would be willing to work harder to understand it.

I would like to validate the use of Creation Stories empirically. Do Creation Stories work better than other forms of content in converting readers to customers? Here’s the deal. I would like to work with up to three teams who sell primarily through the Internet. You must be measuring your current conversion rate. Together we will write your Creation Story and then A/B test it. You must pay me for my help, but as I can’t even speculate on the value of this exercise I will trust you to set the price when the experiment reaches a statistically significant conclusion at what my help was worth to you. Assuming this idea really works well I will be selling this as a premium service. Please contact me if you are interested.

Since I've been a bit pre-occupied with non-Hudson related activities lately, I have missed a few days of link rollups, I suppose it's fitting to get a couple days worth of links in one post.

While The Build Doctor has the time to follow the continuous integration world and post links on a daily basis, I haven't found the same quantity of Hudson links on a day-to-day basis. Therefore, I will be posting a link-rollup every few days. Do let me know if this is too infrequent. That said, here's some interesting links!

• That feels better – Cocoa, Hudson and running green
  • Indie iPhone app developer Jeff Schilling writes about working more efficient with Hudson and Cocoa for developing iPhone apps, he covers OCUnit integration and code coverage with gcovr, a good read for iPhone and Mac developers alike.
• Add CI Build Stability to your Sonar Dashboard
  • Hudson contributor godin (also known as Evgeny Mandrikov) has released a Sonar plugin to report build stability back into Sonar.
• How to get logged-in username in Hudson?
• Switching from CruiseControl to Hudson
  • The developers over at Amaxus wax poetic on reducing their "bus factor" by switching from CruiseControl to Hudson
• Integrating Selenium tests with Hudson CI
  • The folks at InfoStretch have written up a nice, short-and-sweet, overview of getting higher level integration tests built with Selenium to play with Hudson <!--break-->

For those of you living in or around Silicon Valley, next Wednesday (March 10th) you might want to reserve some space around 6pm on your calendar. Frederic Simon and Yoav Landman from JFrog will be presenting at the Silicon Valley JavaFX Users Group meeting at the Googleplex. Frederic and Yoav will be discussing and demonstrating how JFrog's Artifactory works with Hudson to combine continuous integration with release management.

Join with the Artifactory team to realize the benefits of managing your software development life-cycle through continuous integration.

Frederic Simon (JFrog Chief Architect) and Yoav Landman (JFrog CTO) will demonstrate how to automate large-scale multi-module projects, using a fully-integrated platform with Artifactory and Hudson.

Using Maven, Gradle or Ivy builds, it is now possible to dynamically automate and manage the pyramidal stacks of Unit, Functional, and Integration Tests.

This demo-based session will show you how Artifactory and Hudson together make it much easier to promote certified builds to milestone releases , and finally to general availability, while making sure all builds are fully reproducible.

Staying dynamic all through the development process avoids code freeze and provides very accurate feedback loops. This is crucial for Developers, QA teams, System and Integration testers, Users, Customers, and all the remaining actors of the development process.

If you're interested in attending, you can RSVP on the meetup page

Sonar is known as being the open source platform to evaluate and report continuously on source code quality. Its basic role is to evaluate the code technical debt that slows down productivity. Of course, several factors can lead to a productivity slump and poor code quality is only one of them.

Another one is the effectiveness of the Continuous Integration process. CI practice is directly inspired by Lean Manufacturing practices and the main goal is to “Create a continuous process flow to bring problems to the surface … as quick as possible”. When the Continuous Integration flow fails, this is very good feedback to hear : “Hey guys, stop the line. You first need to fix this issue : compilation failure, unit tests failures…”. But if the CI flow fails too often this is also a bad news as lot of time is spent fixing the problem and not developing new features.

The Sonar Build Stability plugin has been developed by Evgeny Mandrikov to evaluate the stability and the effectiveness of this CI flow. It currently enables to answer two questions on a given period of time :

• How long does it take to get valuable feedback ?
• How often was the build broken in the given period ?

Once installed, this plugin is automatically launched by Sonar on every project as long as the Maven pom.xml file contains a “ciManagement” node or that CI engine URL is configured in the plugin. The following new widget is then displayed in the Sonar web interface :

The current version 1.0.1 supports Hudson and Bamboo CI engines. Next version might be extended to cover Teamcity and respond to a third question : “When the build is broken, how long does it take to fix it ?”

This plugin is definitely a great addition to evaluate how Lean we are.

A couple weeks ago in the post outlining the release of Hudson 1.347 I mentioned that Alan Harder (a.k.a. mindless) had undertaken a deprecation-crusade; that is to say Alan has taken it upon himself to rid Hudson's code-base, particularly in the plugin area, of older code. One of Alan's branches old-data-monitor was merged into trunk with r28147 bringing with it some changes to help migrate older plugin datasets to newer formats.

When I reached out to Alan earlier today on IRC (#hudson on the Freenode) about the subject he agreed that polling the community for beta testers would be a good idea; this is where you come in. Per Alan's message to the dev@ mailing list:

Visit your "Manage Hudson" screen to see if the notice about old/unreadable data appears. I'll be curious to see which of the old deprecated data structures are actually out there in people's XML files.

Instead of waiting for the release candidate to be packaged Wednesday evening, I've gone ahead and published the artifact from build #4544 which can be downloaded here: hudson.war

If you have an old Hudson installation with, testing this build would be incredibly useful. Alan went on to say:

If people find issues with OldDataMonitor, they should file them at issues.hudson-ci.org in "core" component and assign them to "mindless".

This change does not mutate any data (or at least it shouldn't) so it should be safe, be on the look out for exceptions in Hudson's log on startup.

Michael Donohue, a Hudson developer who has taken on the role of master bug triage guy for Hudson, does something regularly which I've really come to appreciate as a Hudson developer myself: he sends out emails to the dev list with the top 10 voted issues at that time. This gives those of us in the Hudson development community a good sense of what's really important to our users, which in turn helps us decide where to focus our efforts. If you're interested, you can see the top voted issues over at our JIRA server.

A good number of those issues have been high on the list for a while - I'm actually in the early stages of work on a plugin to answer HUDSON-682, the current #1 most voted-for issue, two and a half years after it was opened. But I'm sure there are some equally useful features Hudson users would like to see added which aren't on that list. So I'm asking you, dear readers: what are you looking for in Hudson that isn't already there? Take a look around the existing issues - you may find a request that fits what you want lurking just out of the top 10, needing only your vote to push it into the spotlight. If no one's yet created an issue requesting your desired feature, well, create one.

Or, better still, write a plugin or contribute a patch yourself!

Editor's Note: If you're interested in writing a plugin, you can check out Hudson's wiki and/or this guide on the subject.

Andrew Bayer (abayer) has been a contributor to Hudson since early 2009, contributing to the ClearCase plugin, Hudson's core and a small number of other plugins. Andrew also helps Kohsuke with a lot of Hudson's project infrastructure, most notably the migration from Bugzilla on Java.net to JIRA running at issues.hudson-ci.org.

A few weeks ago our fearless leader Kohsuke Kawaguchi joined the San Francisco Java Users Group to talk about continuous integration with Hudson. Thanks to Marakana for organizing the meetup, and Aleksandar Gargenta for posting the video and slides, embedded below.

Learn About Continuous Integration With Hudson Directly From the SourceView more presentations from Aleksandar Gargenta.

<!--break-->

"Tests with Parameters" is the KISS approach to testing theories instead of samples. It sometimes is easier to state a tests for any parameters passed in instead of picking one combination and then the next, and the next, ... TwiP can do that for you.

Version 3.0 further reduces the test cruft by allowing you to collect several failing verifications instead of only the first failing assertion. Simply use "verifyThat" instead of "assertThat" and TwiP will throw one exception to JUnit with all the failing verifications at once... it's not "one assert per test", it's "one concept per test".

For more information visit http://twip.sourceforge.net/

The latest release, 1.348 of Hudson was pushed out to the repositories on the 26th of Feb. This release is primarily a bugfix release containing a number of fixes (listed below) and a few localization corrections

Bugs fixed

• Fixed a performance problem of the job/build top page when there are too many artifacts.
• Improved /etc/shadow permission checks.
• DIsable auto-refresh in Groovy script console (issue 5729)

Contributors

This release of Hudson contained 19 commits from 5 different contributors to "core":

• godin
• kohsuke
• swiest
• manuel_carrasco
• rseguy

As usual, you can go grab the latest .war file straight from hudson-ci.org or if you're using a native package, use your package manager to upgrade.

This week we had 18 plugin releases, with the xUnit plugin managing to have a release almost every day. For this edition of TWiP I was actually able to generate the log of releases mostly automatically thanks to rpetti who contributed the script to the contiuous-blog-tools repository on GitHub.

This past week saw two new plugins, the SSH plugin and the Global Build Stats plugin, the latter of which is still in "alpha".

• Feb 19th, 2010

  • Perforce Plugin 1.0.21

• Feb 20th, 2010

  • Monitoring 1.12.0

• Feb 21st, 2010

  • Hudson global-build-stats plugin 0.1-alpha1
  • Hudson Gallio plugin 0.70
  • Hudson cppunit plugin 1.2
  • Hudson Emma plugin 1.12
  • Hudson Backup plugin 1.4.1

• Feb 23rd, 2010

  • Hudson Sonar Plugin 1.3
  • Hudson Gradle plugin 1.3
  • Hudson Sectioned View Plugin 1.10
  • Hudson xUnit plugin 0.6.1

• Feb 24th, 2010

  • Hudson Cpptest plugin 0.3
  • Hudson SSH plugin 1.0
  • Hudson ClearCase UCM Baseline Plug-in 1.3

• Feb 25th, 2010

  • Hudson NAnt Plugin 1.3.1
  • Hudson Ivy plugin 1.1
  • Hudson Bazaar plugin 1.4
  • Dimensions SCM plugin 0.7.0 <!--break-->

• Justifying Continuous Integration Expenditure
  • Our friend the Build Doctor, tries to quantify spending on continuous integration. In the comment thread on another related post of his, he strikes gold with:

People are more expensive than Continuous Integration servers; let’s optimise the system for them.