<?xml version="1.0" encoding="utf-8"?>
<feed version="0.3" xmlns="http://purl.org/atom/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xml:lang="en">
<title>Kohsuke Kawaguchi&apos;s Blog</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/" />
<modified>2009-06-21T23:56:10Z</modified>
<tagline></tagline>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208</id>
<generator url="http://www.movabletype.org/" version="3.01D">Movable Type</generator>
<copyright>Copyright (c) 2009, kohsuke</copyright>
<entry>
<title>Growth of Hudson plugin ecosystem</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/archive/2009/06/growth_of_hudso.html" />
<modified>2009-06-21T23:56:10Z</modified>
<issued>2009-06-21T23:55:45Z</issued>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208.11949</id>
<created>2009-06-21T23:55:45Z</created>
<summary type="text/plain">A Hudson committer Seiji Sogabe put together a chart that shows the growth of the Hudson plugin ecosystem.
</summary>
<author>
<name>kohsuke</name>

<email>Kohsuke.Kawaguchi@Sun.COM</email>
</author>
<dc:subject>Community: Java Tools</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kohsuke/">
<![CDATA[<p>
A Hudson committer <a href="http://d.hatena.ne.jp/ssogabe/20090614/1244955560">Seiji Sogabe</a> put together a chart that shows the growth of Hudson plugins. He wrote a little program that scrapes the download section of the Hudson java.net project, and determined when the first version of each plugins are released.

<p>
The blue bar shows the new plugins released in the given month, and the red bar shows the total number of plugins available to that date. While there are definitely ups and downs in the the pace of releases, he noted a substantial increase in the rate in this year &mdash; 2008 saw 55 new plugins, but in this year, we already have 44 new plugins.

<div align=center>
<img src="http://f.hatena.ne.jp/images/fotolife/s/ssogabe/20090614/20090614135032.png">
</div>

<p>
We need to revise the update center so that people can find the plugins they want more easily. We also need to revise the documentation that explains how to develop a plugin, since the extensibility mechanism and the form design mechanism are both substantially simplified and modernized. I'm also hoping that I'll find some way to list up what plugins extend what extension points, which would help new plugin developers by allowing them to see examples.


]]>

</content>
</entry>
<entry>
<title>Hudson adoption in the Eclipse community survey</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/archive/2009/06/hudson_adoption_2.html" />
<modified>2009-06-10T23:41:34Z</modified>
<issued>2009-06-10T23:41:27Z</issued>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208.11883</id>
<created>2009-06-10T23:41:27Z</created>
<summary type="text/plain">According to Eclipse community survey, Hudson is the most adopted CI tool.</summary>
<author>
<name>kohsuke</name>

<email>Kohsuke.Kawaguchi@Sun.COM</email>
</author>
<dc:subject>Community: Java Tools</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kohsuke/">
<![CDATA[<p>
Eclipse community did <a href="http://www.eclipse.org/org/press-release/20090527_survey09.php">a survey on Java developers</a>, asking various questions.

<p>
One of the questions they had was what build tool they use, and here you can see the adoption of various CI tools:

<div align=center>
<img alt="adoption.png" src="http://weblogs.java.net/blog/kohsuke/archive/20090610/adoption.png" width="724" height="622" />
</div>

<p>
Among CI tools, Hudson is #1 with 128 votes, followed by Cruise Control with 67 votes. Bamboo is in the 3rd with 19 votes, and the rest is insignificant. So this is another validation that Hudson's adoption is going very strong.

<p>
(It's bit strange that they put Ant/Maven and Hudson/CruiseControl all in the same question, but I think we can still use this for the comparison among CI tools.)]]>

</content>
</entry>
<entry>
<title>After-JavaOne project</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/archive/2009/06/afterjavaone_pr.html" />
<modified>2009-06-09T06:34:47Z</modified>
<issued>2009-06-09T06:34:36Z</issued>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208.11860</id>
<created>2009-06-09T06:34:36Z</created>
<summary type="text/plain">JavaOne is always such a big week for me (and many of us) that I need a bit of time to unwind before I go back to my regular routine. So this year, I took on a little hobby project.</summary>
<author>
<name>kohsuke</name>

<email>Kohsuke.Kawaguchi@Sun.COM</email>
</author>
<dc:subject>JavaOne</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kohsuke/">
<![CDATA[<p>
JavaOne is always such a big week for me (and many of us) that I need a bit of time to unwind before I go back to my regular routine. So this year, I took on a little hobby project.

<p>
My daughter is 4 year old now, and so I play with her with LEGO all the time. While building random things, I discovered that I enjoy building spheres, mainly because they are easy :-)

<div align=center>
<img src="http://farm3.static.flickr.com/2447/3610020478_d4bd737dbd.jpg?v=0"><br/>
<img src="http://farm4.static.flickr.com/3643/3610026730_6420e4353f.jpg?v=0"><br/>
</div>

<p>
Then one day while I was playing with her, I thought that I could make a sphere much more smooth if I could make the studs pointing outward in all the directions (instead of just pointing upward like you normally do.)

<p>
I was thinking about how one could do this, but eventually figured out that I can basically do it the way a volleyball is assembled --- by combining 6 pieces of equal shapes around a cube.

<div align=center>
<img alt="2630volley_ball.jpg" src="http://weblogs.java.net/blog/kohsuke/archive/20090608/2630volley_ball.jpg" width="200" height="191" />
</div>

<p>
So I first build a very small sphere in this way, by using pieces that I already have. I liked the result, so I wanted to make a bigger version. Then I thought, building it out of a single color is kind of boring, so, why don't make it a globe?

<div align=center>
<img src="http://farm4.static.flickr.com/3395/3609316509_c0f8c83822_m.jpg">
</div>

<p>
And since I'm a programmer, I hacked together <a href="http://github.com/kohsuke/lego-sphere/tree">a quick Java program to do this</a>. First, a bit of geometric computation to figure out the shape of the 1/6-sphere. 
Then I've expanded the program to compute <a href="http://en.wikipedia.org/wiki/Miller_cylindrical_projection">the Miller cylindrical projection</a> of the resulting LEGO sphere (3 pairs of 1/6-sphere are separately color coded.)

<div align=center>
<img alt="picture2.png" src="http://weblogs.java.net/blog/kohsuke/archive/20090608/picture2.png" width="640" height="469" />
</div>

<p>
I can then overlay this into the Miller cylindrical projection of the earth to determine what color to put where.

<div align=center>
<img alt="Miller-projection.jpg" src="http://weblogs.java.net/blog/kohsuke/archive/20090608/Miller-projection.jpg" width="640" height="469" />
</div>

<div align=center>
<img alt="mapping.png" src="http://weblogs.java.net/blog/kohsuke/archive/20090608/mapping.png" width="640" height="469" />
</div>


<p>
I've also used a LEGO CAD software to virtually build this 1/6-sphere, so that I can figure out (roughly speaking) how many pieces of what kind I need all in all.


<p>
After all that preparation work, finally on Saturday after JavaOne, I started assembling it. My daughter pitched in a little, but this is still too small for her, so I built the most of it, and here's the result.

<p>
Unlike my early prototype, this globe is fully filled inside without any empty space. I built 8 pieces of 6x6x5 brick (because of the dimensions of a lego brick, this is the perfect cube), with 3 1x4 brick with studs on the side, so that when assembled together, the resulting cubic core has studs in all the directions. I'm actually not quite happy with the result, as many of the distinctive northern hemisphere coastal shapes are no longer visible, but Africa and South America are still quite recognizable.

<div align=center>
<img src="http://farm4.static.flickr.com/3596/3609309331_0255153126.jpg?v=0"><br/>
<img src="http://farm4.static.flickr.com/3660/3610124728_86036bbb81.jpg?v=0">
</div>

<p>
I'm already thinking what if I build an even bigger globe &mdash; x1.5 or even x2 on every dimension. Hmm, maybe after next JavaOne...
]]>

</content>
</entry>
<entry>
<title>Starting Hudson slave from Live USB media</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/archive/2009/06/starting_hudson.html" />
<modified>2009-06-07T19:50:15Z</modified>
<issued>2009-06-07T19:49:31Z</issued>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208.11854</id>
<created>2009-06-07T19:49:31Z</created>
<summary type="text/plain">Using Hudson swarm slave plugin to boot a PC from USB and hook it up as a Hudson slave. Translated from Japanese.</summary>
<author>
<name>kohsuke</name>

<email>Kohsuke.Kawaguchi@Sun.COM</email>
</author>
<dc:subject>Community: Java Tools</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kohsuke/">
<![CDATA[(Translated from <a href="http://d.hatena.ne.jp/ssogabe/20090607/1244340438">the original article written in Japanese</a>)
This article shows how to prepare a Live USB stick that becomes a Hudson slave automatically, by using the Hudson swarm plugin.

<h3>Ingredients</h3>
<h4>Hardware</h4>
<ul>
<li>PC that supports USB boot
<li>USB stick (at least 512MB, but depends on the projects to build. I used 8GB)
<li>Functioning DCHP server on the network
</ul>

<h4>Software</h4>
<ul>
<li><a href="http://www.slax.org/">Slax</a> <a href="http://www.slax.org/get_slax.php?download=iso">ISO image</a>.
<li><a href="http://www.slax.org/modules.php?action=detail&id=741">Slax JDK module jdk-6u11-i586-1pst.lzm</a>.
<li>Hudson swarm plugin <a href="http://maven.dyndns.org/2/org/jvnet/hudson/plugins/swarm-client/1.0/">swarm-client-1.0-jar-with-dependencies.jar</a>
</ul>

<h3>Formatting USB stick</h3>
<p>
Format a USB stick with VFAT. The drive needs to have enough space for performing builds.

<h3>Installing Slax</h3>
<blockquote>
Slax is a modern, portable, small and fast Linux operating system with a modular approach and outstanding design. It can be directly booted from a CD or an USB drive. It's based on Slackware, and uses unionfs so that the resulting system is writable (backed by memory, thus without touching HDDs in the system.)
</blockquote>

<p>
Use of USB stick allows us to boot a Hudson slave without modifying the HDDs in the system, and configurations can be persisted.

<p>
First, loop-mount an ISO file and copies files to a USB disk.

<pre>
nanaka # mount -o loop slax-6.1.1-2.iso /mnt/floppy/
nanaka # cd /mnt/floppy
nanaka floppy # ls -la
drwxr-xr-x 4 root root 2048 2009-04-29 14:59 .
drwxr-xr-x 5 root root 4096 2009-06-07 09:29 ..
drwxr-xr-x 6 root root 4096 2009-04-18 16:39 boot
drwxr-xr-x 7 root root 4096 2009-04-18 17:10 slax
nanaka floppy # cp -a boot slax /media/disk (/media/disk is tge USB stick)
</pre>

<p>
Run <tt>boot/bootinst.sh</tt> to set up MBR on the USB stick.

<pre>
nanaka disk # cd /media/disk/boot        
nanaka boot # ./bootinst.sh 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                        Welcome to Slax boot installer                         
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This installer will setup disk /dev/sdb1 to boot only Slax.

Warning! Master boot record (MBR) of /dev/sdb will be overwritten.
If you use /dev/sdb to boot any existing operating system, it will not work
anymore. Only Slax will boot from this device. Be careful!                 

Press any key to continue, or Ctrl+C to abort...

Flushing filesystem buffers, this may take a while...
Setting up MBR on /dev/sdb...
The Master Boot Record of  /dev/sdb  has been updated.
Activating partition /dev/sdb1...
No partition table modifications are needed.
Updating MBR on /dev/sdb...
Setting up boot record for /dev/sdb1...
Disk /dev/sdb1 should be bootable now. Installation finished.

Read the information above and then press any key to exit...
</pre>

<p>
This completes a USB-bootable Slax.

<h3>Installing JDK</h3>
<p>
To start a Hudson swarm plugin, we need a JDK. Slax already has a module <a href="http://www.slax.org/modules.php?action=detail&id=741">jdk-6u11-i586-1pst.lzm</a>, so we'll install this.

<p>
With Slax, one only needs to place modules to <tt>slax/modules</tt> directory, and they'll be automatically made available upon boot. 

<pre>
nanaka #cp jdk-6u11-i586-1pst.lzm /media/disk/slax/modules/
</pre>

<p>
If 6u11 is too old for you, non-official package of 6u14 is available from <a href="http://bacons.ddo.jp/download/jdk-6u14-i586-1pst.lzm">here</a> for your convenience.

<p>
At this point, boot from USB and continue configuration from Slax. A successful boot should result in a KDE environment:

<div align=center>
<img src=http://f.hatena.ne.jp/images/fotolife/s/ssogabe/20090607/20090607184042.png>
</div>

<h3>User Account</h3>
<p>
Create an user account that runs the Hudson swarm client. We could just use root for this, but we'll create the 'hudson' user in the 'hudson' group:

<pre>
root@slax:~# addgroup hudson
root@slax:~# useradd -g hudson -d /home/hudson -s /bin/bash hudson
root@slax:~# mkdir /home/hudson
root@slax:~# chown hudson:hudson /home/hudson
</pre>

<h3>Installing Hudson Swarm Slave</h3>
<p>
Put the swarm client in <tt>/home/hudson</tt> and create fsrot:

<pre>
root@slax:~# su - hudson
hudson@slax:~$ mkdir fsroot
hudson@slax:~$ ls 
fsroot/  swarm-client-1.0-jar-with-dependencies.jar
</pre>

<h3>Auto-starting Swarm Client</h3>
<p>
Modify <tt>/etc/rc.d/rc.local</tt> to start the swarm client automatically upon boot:

<pre>
root@slax:~# cat /etc/rc.d/rc.local
#!/bin/sh
#
# /etc/rc.d/rc.local:  Local system initialization script.
#
# Put any local startup commands in here.  Also, if you have
# anything that needs to be run at shutdown time you can
# make an /etc/rc.d/rc.local_shutdown script and put those
# commands in there.

USER=hudson
USER_HOME=/home/${USER}
CLIENT=${USER_HOME}/swarm-client-1.0-jar-with-dependencies.jar
LOG=${USER_HOME}/hudson.log

JAVA_HOME=/usr/lib/java

# Swarm client option
DESCRIPTION="SLAX Live-USB"
EXECUTORS=2
FSROOT=${USER_HOME}/fsroot
LABELS="Swarm"

hudson_start() {
if [ -e ${CLIENT} ]; then
        /bin/su - "${USER}" \
        -c \
        "${JAVA_HOME}/bin/java -jar \"${CLIENT}\" \
        -description \"${DESCRIPTION}\" \
        -executors \"${EXECUTORS}\" \
        -fsroot \"${FSROOT}\" \
        -labels \"${LABELS}\" \
        > \"${LOG}\" 2>&1  &"
fi
}

hudson_start
</pre>

<p>
Similarly, tweak <tt>/etc/rc.d/rc.local_shutdown</tt> to terminate the swam client and clean up log files, etc.

<pre>
root@slax:~# cat /etc/rc.d/rc.lo
rc.local           rc.local_shutdown
root@slax:~# cat /etc/rc.d/rc.local_shutdown
#!/bin/sh
#
USER=hudson
USER_HOME=/home/${USER}
LOG=${USER_HOME}/hudson.log
FSROOT=${USER_HOME}/fsroot

hudson_stop() {
        PID=`ps ax | grep swarm-client | grep -v grep | awk '{ print $1 }'`
        if [ -n "${PID}" ]; then
                /bin/kill "${PID}" > /dev/null 2>&1
        fi
        if [ -e "${LOG}" ]; then
                /bin/rm "${LOG}" > /dev/null 2>&1
        fi
        for jar in "${FSROOT}"/maven*.jar ; do
                /bin/rm "${jar}" > /dev/null 2>&1
        done
}

hudson_stop
</pre>

<h3>Verify That Everything Works</h3>
<p>
Start the swarm client and make sure that everything works as expected.

<pre>
root@slax:~# /etc/rc.d/rc.local
root@slax:~# ps aux | grep swarm
hudson   14414  9.4  1.2 662988 25576 pts/1    Sl   19:47   0:00 /usr/lib/java/bin/java -jar /home/hudson/swarm-client-1.0-jar-with-dependencies.jar -description SLAX Live-USB -executors 2 -fsroot /home/hudson/fsroot -labels Swarm
root     14465  0.0  0.0   2972   824 pts/1    S+   19:48   0:00 grep swarm
</pre>

<p>
Verify that the client is connected by looking at the Hudson node management scren:

<div align=center>
<img src="http://f.hatena.ne.jp/images/fotolife/s/ssogabe/20090607/20090607204746.png">
</div>
<p>
And its configuration screen:

<div align=center>
<img src="http://f.hatena.ne.jp/images/fotolife/s/ssogabe/20090607/20090607205115.png">
</div>

<p>
Now shut down the system. Don't remove the USB stick until the system is fully halted.

<h3>Inspecting the USB Stick</h3>
<p>
Bring the USB back to another system to take a look at what's inside.

<pre>
sogabe@nanaka ~/Desktop $ cd /media/disk/
sogabe@nanaka /media/disk $ ls
boot  slax
sogabe@nanaka /media/disk $ cd slax/
sogabe@nanaka /media/disk/slax $ ls
GNU_GPL  base     cheatcodes.txt  livecd.sgn    make_iso.sh  optional          rootcopy      tools
LICENSE  changes  images          make_iso.bat  modules      requirements.txt  slaxsave.zip  xino
sogabe@nanaka /media/disk/slax $ cd changes/
sogabe@nanaka /media/disk/slax/changes $ ls
dev  etc  home  lib  mnt  opt  root  tmp  usr  var
sogabe@nanaka /media/disk/slax/changes $ cd home/hudson
sogabe@nanaka /media/disk/slax/changes/home/hudson $ ls
fsroot  swarm-client-1.0-jar-with-dependencies.jar
</pre>

<p>
You can see that <tt>slax/changes</tt> contains files that we just created above. If further changes are necessary, just modify these files. Slax also copies all the files in <tt>slax/rootcopy</tt> into the real '/' upon boot, so for example if you want <tt>/home/hudson/fsroot</tt> after booth, you can create <tt>slax/rootcopy/home/hudson/fsroot</tt> in the USB stick.

<p>
This completes the Live USB version of the Hudson swarm client. Slax makes it really easy to do this.]]>

</content>
</entry>
<entry>
<title>Slides for the Hudson technical session</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/archive/2009/06/slides_for_the.html" />
<modified>2009-06-04T16:04:06Z</modified>
<issued>2009-06-04T16:03:52Z</issued>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208.11824</id>
<created>2009-06-04T16:03:52Z</created>
<summary type="text/plain">I posted my slides for the JavaOne 2009 Hudson technical session</summary>
<author>
<name>kohsuke</name>

<email>Kohsuke.Kawaguchi@Sun.COM</email>
</author>
<dc:subject>Community: Java Tools</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kohsuke/">
<![CDATA[The slides are available <a href="http://wiki.hudson-ci.org/download/attachments/37323793/Hudson+J1+2009.ppt?version=1">here</a>.]]>

</content>
</entry>
<entry>
<title>JavaOne activities around Hudson</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/archive/2009/05/javaone_activit.html" />
<modified>2009-05-28T19:59:57Z</modified>
<issued>2009-05-28T19:59:42Z</issued>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208.11740</id>
<created>2009-05-28T19:59:42Z</created>
<summary type="text/plain">JavaOne/CommunityOne 2009 is just a few days away, and here&apos;s the list of activities around Hudson in JavaOne/CommunityOne.</summary>
<author>
<name>kohsuke</name>

<email>Kohsuke.Kawaguchi@Sun.COM</email>
</author>
<dc:subject>Community: Java Tools</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kohsuke/">
<![CDATA[<p>
JavaOne is just a few days ahead now, so let me recap what's happening around <a href="https://hudson.dev.java.net/">Hudson</a> during JavaOne.


<p>
On Sunday, we have Unconference (<a href="http://wikis.sun.com/display/GlassFishConferences/GlassFish+2009+unconference+planning">RSVP</a>) and a party at the Thirsty Bear (RSVP to "<tt>RSVP-ThirstyBear2009 at sun dot com</tt>".) The great thing about Unconference is that we have a big block of time (6 hours, in fact, if I'm reading it right), where enough people gather. So we have enough time to really talk about where the project should go, what we need to do, and hear what others are doing. If you have a plugin coding questions, I think this would be also a good time to bring them.

<p>
On Monday, Eduardo, my boss, will kick off what I think as "the GlassFish track" in CommunityOne at 10:50am. He'll cover the entire GlassFish Portofolio, of which Hudson is a part. I believe he'll touch Hudson, and where Sun wants to take Hudson at the higher level. The next session in the same room is from Lukas Hasik and Tomas Musil titled <b>"Test Your Product on Multiple Machines in Parallel with Hudson"</b>. This part of CommunityOne is a free event (<a href="http://www.cplan.com/communityone2009/west/externalregistration">register</a>.)

<p>
On Wednesday, I'll be presenting a technical session <b>"TS-5301 Continuous Integration in the Cloud with Hudson"</b> with Jesse from 9:45am. In the evening, there's <b>"BOF-5105 Hudson Community Meet-up"</b> from 7:45pm, where we'll see a lot more demo from multiple folks.

<p>
Throughout CommunityOne and JavaOne, I'll be mostly at the Hudson booth in the pavilion floor. This is a great opportunity to have face-to-face time, and so especially if you want me to fix some problems on the spot, or talk about the ideas/problems/questions, please come by! This part of JavaOne is free as long as you have <a href="http://www.cplan.com/communityone2009/west/externalregistration">registration</a>.

<p>
Finally since JavaOne attracts people from all over the world, we'll be doing <b>"Hudson Localization Festa"</b> by using <a href="http://wiki.hudson-ci.org/display/HUDSON/Translation+Assistance+Plugin">the new Hudson translation assistance plugin</a>. You can come to the booth, look at a few pages, choose your locale, then type the translations in there, and we'll integrate that into Hudson.

<p>
Hope to see you soon next week!]]>

</content>
</entry>
<entry>
<title>Hudson swarm slave plugin</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/archive/2009/05/hudson_swarm_sl.html" />
<modified>2009-05-24T00:20:19Z</modified>
<issued>2009-05-24T00:20:11Z</issued>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208.11687</id>
<created>2009-05-24T00:20:11Z</created>
<summary type="text/plain">Hudson swarm slave plugin enables a computer to automatically join a nearby Hudson master as a slave, thereby enabling a self-organizing Hudson cluster.</summary>
<author>
<name>kohsuke</name>

<email>Kohsuke.Kawaguchi@Sun.COM</email>
</author>
<dc:subject>Community: Java Tools</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kohsuke/">
<![CDATA[<p>
I run a budget-less Hudson cluster, just like many of you do, and one of the challenges is to have enough computing resources in a cluster. I rely on recycled computers as the main workhorse, so I constantly look for unused computers under people's desks, and when people give them to me, I reinstall them as Hudson slaves.

<p>
In this process, I learned a lesson; people don't like to be separated from their computers, even long after they stopped using them, because they think they might occasionally need them in the future, or they may later discover that they forgot to copy some data to their new computers. That is, what's really happening is that the idea of your computer getting reformatted makes them nervous, and that is entirely understandable &mdash; if you'll never see it again, you better darn sure that you won't never ever need it, right?

<p>
Therefore, a better approach is to let them keep the computers, and instead ask them to run a slave as a virtual machine. Even better, such a set up would even let me ask them to run the VM on their newer computers, too, because it's very easy to see that a VM won't jeopardize their systems. With a little bit of VirtualBox Python API programming, I can make it so that the VM only runs when no one else is logging in, by using the memory and virtual disk that are proportional to the host system.

<p>
Or you can take this even further and just login to all the machines on the network, and just start a VM everywhere you can.

<p>
Toward that goal, I released <a href="http://wiki.hudson-ci.org/display/HUDSON/Swarm+Plugin">the Hudson swarm slave plugin</a>. This plugin comes with a little CLI agent, which uses a UDP broadcast to discover a nearby Hudson master, that's equipped with the Hudson swarm plugin. It then hooks up the slave on the fly, and joins the cluster, then Hudson will start running builds and tests on this swarm CLI agent.

<p>
With the recent improvements in Hudson to automatically install JDKs, Ants, and Mavens from the network, this instantly turns a plain-vanilla PC into a working Hudson slave, without administrators manually registering the new slave. I think this opens up a whole new way of creating a Hudson cluster, in a somewhat self-organizing fashion.

<p>
So there, Mahesh, that's how I plan to recruit your 3 beautiful Sun workstations with Core 2 Extreme CPUs. I know you are not really using them... :-)]]>

</content>
</entry>
<entry>
<title>Project of the day: SSH daemon for EC2 Windows AMIs</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/archive/2009/05/project_of_the.html" />
<modified>2009-05-20T09:07:35Z</modified>
<issued>2009-05-20T09:07:22Z</issued>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208.11665</id>
<created>2009-05-20T09:07:22Z</created>
<summary type="text/plain">As a project of the day, I developed a SSH daemon for EC2 Windows AMIs, which otherwise do not have any scriptable remote access technology.</summary>
<author>
<name>kohsuke</name>

<email>Kohsuke.Kawaguchi@Sun.COM</email>
</author>
<dc:subject>Community: Java Tools</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kohsuke/">
<![CDATA[<p>
In my attempt to make <a href="http://weblogs.java.net/blog/kohsuke/archive/2009/05/hudson_ec2_plug.html">Hudson EC2 plugin</a> (which <a href="http://weblogs.java.net/blog/kohsuke/archive/2009/05/hudson_ec2_plug.html">I blogged earlier</a>) work with Windows AMIs, I wrote <a href="ec2-sshd.dev.java.net">a little SSH daemon</a>.



<p>
Here's the problem statement. Windows AMIs on EC2 do not have any built-in programmable remote access technology. This is a really poor packaging job of Amazon &mdash; their documentation talks about doing the remote desktop protocol (RDP) to talk to the server. This obviously prevents programs like Hudson to talk to the launched Windows instances.

<p>
The program I wrote is an SSH daemon, in the sense that it speaks SSH protocol, but at the same time, it's not a real SSH daemon. It's packaged specifically for EC2 use cases.

<p>
For example, it's not capable of launching a process in a different user account. Regardless of the user name that you provided to the authentication, the daemon will always create a new process with the same user that the daemon itself runs. It also only accepts a public key authentication, and you must provide a key you used to launch the EC2 instance. This is the most critical part of this daemon, which makes sure that only the authorized users can access the instance.

<p>
The daemon implements SCP and process execution part of SSH, so you can copy files both ways, and start arbitrary proceses on the server (and connect stdin/out/err to SSH client.) OTOH, Windows don't have the terminal in the same way Unix does, so launching a shell wouldn't really work.

<p>
For more about the project, see <a href="https://ec2-sshd.dev.java.net/">the project website</a>.
]]>

</content>
</entry>
<entry>
<title>Hudson EC2 plugin</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/archive/2009/05/hudson_ec2_plug.html" />
<modified>2009-05-19T00:27:22Z</modified>
<issued>2009-05-19T00:27:13Z</issued>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208.11654</id>
<created>2009-05-19T00:27:13Z</created>
<summary type="text/plain">I released Hudson EC2 plugin, which enables you to use EC2 as Hudson slaves on-demand, without human intervention.</summary>
<author>
<name>kohsuke</name>

<email>Kohsuke.Kawaguchi@Sun.COM</email>
</author>
<dc:subject>Community: Java Communications</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kohsuke/">
<![CDATA[
<p>
Continuous Integration often requires a heterogeneous environments; for example, the GlassFish build requires Linux, Solaris, and Windows, and the JDK build requires something like 10 different environments, each carefully created so that we can test what we need to test.

Unfortunately, heterogeneous environments reduce the resource utilization &mdash; you can easily have some Windows slaves idle while all the Solaris slaves are busy, just because you happen to have more jobs that require Solaris. So doing some kind of virtualization makes a lot of sense.

<p>
Similarly, CI jobs tend to be spiky. When you need computring resources, you need them a lot (think about a month before a release, where all kinds of tests run like crazy for almost every commit), but when you don't need them, you don't. These charateristics of CI makes it a great fit with the cloud computing technology. You can have a good resource utilization and faster turn-around time (if your tests can run in parallel.)

<p>
Toward this end, I just released <a href="http://wiki.hudson-ci.org/display/HUDSON/Amazon+EC2+Plugin">the Hudson EC2 plugin</a>. This plugin enables Hudson to automatically provision new instances on EC2, based on the system demand. That is, if Hudson notices that your system is overloaded, it will provision new slaves on EC2, and when those instances go unused for a certain time period, it will shut them down. You can run all your slaves on EC2 if you want, or you can maintain your local build cluster and use EC2 as a reserve capacity.


<p>
And here's how to use the plugin. First, go to <a href="http://aws.amazon.com/ec2/" rel="nofollow">EC2</a> and sign up for the service. Then enter the username/password information. Because of the way EC2 works, you also need to have an RSA private key. If you have already been using EC2 and have your own key, you can paste it here. Otherwise, you can have Hudson generate one. If you let Hudson generate one, you should save this private key in your file system as well, as you'll need this to interactively logon to EC2 instances. Use "Test Connection" button to verify that Hudson can successfully talk to EC2.</p>

<p><div align="center"><img src="http://wiki.hudson-ci.org/download/attachments/37324430/ec2-credential.png" border="0" /></div></p>

<p>Next, configure AMIs that you want to launch. For this, you need to find the AMI IDs for the OS of your choice. <a href="http://developer.amazonwebservices.com/connect/entry.jspa?externalID=609" rel="nofollow">ElasticFox</a> is a good tool for doing that, but <a href="http://docs.amazonwebservices.com/AmazonEC2/dg/2006-10-01/CLTRG-describe-images.html" rel="nofollow">there are a number of other ways to do it</a>. Hudson can work with any Unix AMIs. Windows is currently unsupported.</p>

<p>Configuring labels allow Hudson to pick the right AMI to start. For example, if all your existing slaves labeled "solaris" are fully busy and you have more builds that are tied to the "solaris" label, Hudson will start the AMIs that have the "solaris" label.</p>

<p>Init script is the shell script to be run on the newly launched EC2 instance, before Hudson starts launching a slave agent. If the AMI doesn't have Java pre-installed, you need to do so in this script. This is also a good place to install additional packages that you need for your builds and tests.</p>

<p><div align="center"><img src="http://wiki.hudson-ci.org/download/attachments/37324430/ec2-ami.png" border="0" /></div></p>


<p>
The load monitoring part is in the core, so the EC2 plugin really just contains some glue code that talks to EC2 to provision a new system. This means we can easily write simialar plugins for different clouds and virtualization technologies. For example, someone in the community is writing a plugin that do this with VMWare labmanager. VirtualBox lets us do something similar, with its web services (for which I wrote <a href="http://weblogs.java.net/blog/kohsuke/archive/2008/05/virtualbox_web.html">a JAX-WS client library</a> some time ago, so might be fun to eat my own dogfood, so to speak.) <a href="http://weblogs.java.net/blog/vivekp/">Vivek</a> and I also installed <a href="http://www.eucalyptus.com/">Eucalyptus</a> on our spare machines, so I hope to be able to extend this plugin to work with that, too.


<p>
I'm going to talk more about this (and other things) in my JavaOne talk, so if you are coming to JavaOne, please consider dropping by!]]>

</content>
</entry>
<entry>
<title>Hudson Selenium Grid Plugin</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/archive/2009/05/hudson_selenium.html" />
<modified>2009-05-16T15:45:47Z</modified>
<issued>2009-05-16T15:45:37Z</issued>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208.11650</id>
<created>2009-05-16T15:45:37Z</created>
<summary type="text/plain">I&apos;ve released the Hudson Selenium Grid plugin, which instantly lets you deploy Selenium Grid on top of your existing Hudson cluster. By using this plugin, you
can start using Selenium Grid without installing it on individual
machines in the cluster manually.</summary>
<author>
<name>kohsuke</name>

<email>Kohsuke.Kawaguchi@Sun.COM</email>
</author>
<dc:subject>Community: Java Tools</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kohsuke/">
<![CDATA[<p>
I've released <a
href="http://wiki.hudson-ci.org/display/HUDSON/Selenium+Plugin">the
Hudson Selenium plugin</a>, which instantly lets you deploy Selenium
Grid on top of your existing Hudson cluster. By using this plugin, you
can start using Selenium Grid without installing it on individual
machines in the cluster manually. This is the latest addition to the
family of plugins that let you reuse you Hudson cluster infrastructure
for additional purposes.


<p>
Once you install this plugin from the update center, Hudson master
will become the Selenium Grid hub, the center of the Selenium Grid
system. Similarly, each slave that you have in your cluster will now
run Selenium RCs. The whole process happens completely automatically,
without any additional configuration.

<p>
To connect to this grid from your Selenium tests, create a
<tt>DefaultSelenium</tt> instance by specifying the host name of your
Hudson master, like this:

<pre>new DefaultSelenium("hudson.mydomain", 4444, "*firefox", "http://site.that.iam.testing/");</pre>

<p>
By default, Selenium Grid randomly chooses a Selenium RC to carry out
the execution, but this behavior makes it difficult to reliably start
a platform dependent browser (like IE and Safari), that needs to be
run on specific computers. As such, it's convenient to be able to
specify the slave that runs the browser. To do this, Hudson Selenium
Grid plugin extends the stock Selenium Grid by extending the browser
identifier. Specifically, you can specify
"label1&amp;label2&amp;...:browser" to tell Selenium Grid to start the
specified browser on a slave that has all the given labels. For
example, if your Windows slaves have the "windows" label, the browser
identifier of "windows:*iexplore" would cause a Selenium RC on some
Windows slave to start the IE.

<p>
We are increasingly seeing tools like Hadoop and Selenium, which
requires a cluster of computers to operate. Given the rise of
multi-core systems, cloud computing, and other general shift for
increased parallelism, I expect this trend to continue. Now, the
problem of those tools is that it's harder to set them up and keep
them going. One of the things I want to do with Hudson is to enable
their deployments on the Hudson cluster. I think this is a convincing
value proposition, given that Hudson byitself is pretty easy to
install and maintain (even on a cluster), and that it already has an
update center built-in.

<p>
I intend to talk more about this in my JavaOne session, so please drop by!]]>

</content>
</entry>
<entry>
<title>Hudson PXE plugin 1.0 is released</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/archive/2009/05/hudson_pxe_plug.html" />
<modified>2009-05-12T07:17:13Z</modified>
<issued>2009-05-12T07:17:06Z</issued>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208.11625</id>
<created>2009-05-12T07:17:06Z</created>
<summary type="text/plain">A new Hudson plugin automates installation of OS on PCs. And as with everything else in Hudson, it&apos;s very easy to use.</summary>
<author>
<name>kohsuke</name>

<email>Kohsuke.Kawaguchi@Sun.COM</email>
</author>
<dc:subject>Community: Java Tools</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kohsuke/">
<![CDATA[<p>
Whether you recycle old PCs or use new ones as Hudson slaves, you have to first install an OS on a system. As the Hudson cluster I managed gets bigger, I find this more and more painful. You have to have a CD of the OS, and you have to have a working CD-ROM drive (somehow on recycled PCs, CD-ROM drives are often unreliable.)

<p>
Then the installation itself is rather boring, yet it's interactive. You have to answer multiple questions, for which your answers are always identical. After the OS gets installed, you have to go through a series of initial set up, like installing packages, pointing the package manager to a mirror, creating an user, etc.

<p>
On most Unix, these steps can be totally automated, by configuring installers to run with canned answers, plus a post-installation script. You can also eliminate the need of CD by network-booting your PC (AKA PXE boot.)

<p>
There are many documentats that show you how to do this, but they have a problem. Aside from the fact that none of them really talk about how you set up one PXE boot server to support multiple different OSes, it's all rather tedious, and I hate tedious things.

<p>
So I did what I normally do. Just push the job to Hudson! And that's how I wrote a plugin that makes this whole thing much simpler, and it is available now as <a href="http://wiki.hudson-ci.org/display/HUDSON/PXE+Plugin">Hudson PXE plugin</a>. This is one of my many attempts to bring distributed builds closer and more affordable to people.

<p>
The plugin can be installed from your Update center, as usual. Currently it supports OpenSolaris, Ubuntu, Fedora, and CentOS, and OS support is extensible, so your contributions are appreciated. You first download the ISO images of those OSes (see Wiki for exactly which variation you need to download), then tell Hudson where those ISO files are. And that's all you need to do.

<p>
Now, put a PC on the same network as Hudson, start it, and press F12 to initiate a network boot. You'll see a menu of all the OSes that Hudson has, like this:

<div align=center>
<img src=http://wiki.hudson-ci.org/download/attachments/37323889/pxe-bootmenu.png>
</div>

<p>
You can then choose to silent-install this OS, or interactively install it (convenient if you are installing your own PC, not Hudson slaves.)

<div align=center>
<img src=http://wiki.hudson-ci.org/download/attachments/37323889/pxe-ubuntu-menu.png>
</div>

<p>
Also, I should point out that this plugin works nicely with existing DHCP servers on the network. This plugin doesn't touch them at all. There's also a separate tool that you can use to install PCs on different networks from where Hudson master is running.

<p>
With a bit more work done on Hudson CLI, we should be able to automate the entire thing, up to the registration of a slave to Hudson. Wouldn't that be really nice? &mdash; power on a new PC, hit F12, let it run for an hour and you have a new Hudson slave, fully configured and ready for action!]]>

</content>
</entry>
<entry>
<title>Automatic Continuous Integration for Grails projects on Google Code</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/archive/2009/05/automatic_conti.html" />
<modified>2009-05-08T19:28:43Z</modified>
<issued>2009-05-08T19:28:21Z</issued>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208.11609</id>
<created>2009-05-08T19:28:21Z</created>
<summary type="text/plain">Another cool stuff around Hudson, which automatically craws Grails projects from Google Code and builds them on Hudson.</summary>
<author>
<name>kohsuke</name>

<email>Kohsuke.Kawaguchi@Sun.COM</email>
</author>
<dc:subject>Community: Java Tools</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kohsuke/">
<![CDATA[<p>
Japan is in the middle of a week long holiday this week, so our Japanese Hudson committers are cranking out a lot of cool stuff.
<a href="http://d.hatena.ne.jp/kiy0taka/20090506/1241617225">This one is from Kiyotaka</a>, who wrote a Hudson plugin called GCrawler.

<p>
GCrawler (1) searchs Google Code and discovers all Grails projects, (2) reads Subversion repository to figure out metadata, and (3) automatically add them to Hudson and builds them.
The net result is a free CI service for Grails projects on Google Code. It even creates views for different versions of Grails.

<div align=center>
<img src=http://img.skitch.com/20090506-gmm18mnupyftjk1fqbtg6ic29s.png>
</div>

<p>
You can see <a href="http://ghudson.morphexchange.com/gcrawler/">the live instance and the list of the whole thing from here</a>. He also wrote "It'd be nice to support Griffon as well, and hope G2one folks would get to do it"  &mdash; so I guess here's a gauntlet on the ground for G2one folks! :-)

<p>
On top of all this, this Hudson runs on a cloud &mdash; in <a href="http://www.morphexchange.com/">Morph eXchange</a>. My hat off to Kiyotaka.]]>

</content>
</entry>
<entry>
<title>Hudson&apos;s growth chart</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/archive/2009/05/hudsons_growth.html" />
<modified>2009-05-07T19:20:05Z</modified>
<issued>2009-05-07T19:19:38Z</issued>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208.11608</id>
<created>2009-05-07T19:19:38Z</created>
<summary type="text/plain">Seiji Sogabe, a Hudson committer, put together Hudson&apos;s growth chart.</summary>
<author>
<name>kohsuke</name>

<email>Kohsuke.Kawaguchi@Sun.COM</email>
</author>
<dc:subject>Community: Java Tools</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kohsuke/">
<![CDATA[<p>
This is from Seiji Sogabe, who is a Hudson committer. He <a href="http://d.hatena.ne.jp/ssogabe/20090506/1241565289">put together a chart of the <tt>hudson.war</tt> size</a> from 1.100 to 1.300. This is another way to see the progress in Hudson.

<div align=center>
	<img src="http://f.hatena.ne.jp/images/fotolife/s/ssogabe/20090506/20090506081325.png">
</div>

<p>
Off the top of my head, a big jump in 1.160 or so is probably the native Maven2 support, but I don't know what's the jump around 1.280 &mdash; maybe we picked up extra unnecessary dependencies? With Maven, it's so easy to get more than what you need accidentally. I should take a look when I can...
]]>

</content>
</entry>
<entry>
<title>Hudson CLI and Groovy shell</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/archive/2009/05/hudson_cli_and.html" />
<modified>2009-05-02T16:27:42Z</modified>
<issued>2009-05-02T16:26:51Z</issued>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208.11573</id>
<created>2009-05-02T16:26:51Z</created>
<summary type="text/plain">Hudson 1.302 has a new CLI program to Hudson, and one of the first commands is an interactive groovy shell so that you can look at and change live Hudson servers.</summary>
<author>
<name>kohsuke</name>

<email>Kohsuke.Kawaguchi@Sun.COM</email>
</author>
<dc:subject>Community: Java Tools</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kohsuke/">
<![CDATA[<p>
"You can do everything from GUI" has always been one of Hudson's strengths, and we also have the REST API, but at the same time, CLI is also very useful for improving automation around administration, builds, and so on. So starting Hudson 1.302, I added a CLI agent to Hudson. CLI can be downloaded from your Hudson from <tt>http://server/hudson/cli</tt>, which also shows you the basic usage.

<p>
Internally, the interesting implementation detail of this CLI is that CLI is "dumb" &mdash; it doesn't have any hard-coded knowlege of any command, and instead it downloads the necessary code on-demand from the master via the same remoting technology that Hudson uses between the master and slaves, which is rather transparent to the program running on it.

<p>
This enables a single CLI jar to morph into whatever command that plugins on the master has provided. And once the necessary code is obtained, the CLI command can choose what to execute locally in CLI agent and what to execute on the master, making the optimal use of network.

<p>
As one of the first commands, I implemented a <a href="http://groovy.codehaus.org/Groovy+Shell">Groovy shell</a>, which can be started like this:

<pre>
$ java -jar hudson-cli.jar -s http://yourserver/hudson groovysh
<b>Groovy Shell</b> (1.6.0, JVM: 1.6.0_02-fastdebug)
Type '<b>help</b>' or '<b>\h</b>' for help.
-------------------------------------------------------------------------------
<b>groovy:000&gt</b>;
</pre>

<p>
The underlying remoting technology enabled us to write this command in a single Java class of 45 lines (including empty lines and comments), so you can see how easy it is to write a new command in Hudson.

<p>
Since this shell is connected to the live Hudson instance, you can introspect the state of the running Hudson instance, or even changes them on the fly.

<pre>
<b>groovy:000&gt;</b> import hudson.model.*;
<b>===&gt;</b> [import hudson.model.*;]
<b>groovy:000&gt;</b> Hudson.instance
<b>===&gt;</b> hudson.model.Hudson@4b09558d
</pre>

<p>
For example, you can define a new builder class in Groovy, and add it to your project, all on a live system (not that it's recommended, but it's a very useful tool for inspecting problems and applying  a temporary bandaid.)  This is also very useful if you are writing plugins and try out Hudson's behaviors. The interactivity of Groovy shell allows you to quickly figure out what API has what effects, which you can in turn bake into your code.

<p>
All in all, I really like Groovy. And if you have ideas about the CLI commands you'd like to see, please let us know.
]]>

</content>
</entry>
<entry>
<title>Hudson hits 1.300</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kohsuke/archive/2009/04/hudson_hits_130.html" />
<modified>2009-04-22T15:21:19Z</modified>
<issued>2009-04-22T15:21:01Z</issued>
<id>tag:weblogs.java.net,2009:/blog/kohsuke/208.11502</id>
<created>2009-04-22T15:21:01Z</created>
<summary type="text/plain">Hudson has reached version 1.300.</summary>
<author>
<name>kohsuke</name>

<email>Kohsuke.Kawaguchi@Sun.COM</email>
</author>
<dc:subject>Community: Java Tools</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kohsuke/">
<![CDATA[<p>
Hudson has reached version 1.300 last Friday. While it's not like this release is fundamentally different from any other past releases, it does feel like it is some kind of a milestone.

<p>
The community continues to grow. We have around <a href="http://markmail.org/search/?q=list%3Anet.java.dev.hudson">1500 human-generated e-mails per month</a> nowadays, with 7500/wk or so downloads of <tt>hudson.war</tt>. Access to the update center is increasing steadily last time I checked (although I don't have the numbers right now.) There are 137 plugins right now and 120 committers, and according to my JavaOne 2008 slides, that's up from 50+ and 50+ each in June 2008. We've added many user visible features, such as update center, better Windows integrations, load average monitoring on a cluster, preventive failed node detection in a cluster, and so on. There are improvements in areas that's not so visible, too, such as a new modern mechanism for plugins to define/implement extension points, or more convention-over-configuration to reduce the amount of Jelly coding you'd have to do. IDE plugins for authoring Hudson plugins have improved, too, and relevant Maven mojos that we write contains a lot more error diagnostics to assist the plugin developers. Oh, and last but certainly not least, much better test coverage.

<p>
So thank you for all the contributers (and if you'd like to become one you just need to tell us so &mdash; our commit access is open to almost anyone), and thank you for all the users who continue to guide us and help us make the project better.

<p>
Hudson has recently adopted <a href="http://www.nabble.com/New-release-plan-tp22441320p22495137.html">a new release model</a>, which involves reduced release frequency (of once a week, so it's still not too infrequent) and longer soaking period via a release branching. So in this pace, 1.400 will be about 2 years from now.

<p>
BTW, this somewhat unusual linear version numbering scheme reflects the train model of releases &mdash; each release contains fixes and features that are available at that time, and the trunk is kept usuable almost all the time. If I call it 1.2.99 instead of 1.299, I'd create a false impression that somehow 1.2.99 -> 1.3.0 is a far more significant update than 1.2.98 to 1.2.99.

]]>

</content>
</entry>

</feed>