I am using Apache Continuum as a continuous integration server to test Netty, the Java NIO Client Server Network Application Framework.

I’m pretty satisfied with the CI server since it’s running more than 1000 Netty test cases about 4000 times a day with 7 different JDKs (see the live report here). It increases the chance for me to catch a hidden race conditions which might cause a problem in a production environment. I actually was able to find a couple critical issues like a dead lock thanks to the intensive automated testing.

However, the caveat of running big number of tests a day is that too many build results are filed into the build report database, slowing down the overall performance of the CI server. Moreover, Continuum doesn’t provide the paginated view of build results at this moment, and therefore the large number of build results can lead to high memory footprint and poor UI response time.

So, I ended up with a simplistic tool that removes the successful build results which are older than the certain amount of time (e.g. 6 hours). Continuum provides an easy-to-use client API which is based on XML–RPC, so it didn’t took long.

I run reap-old-builds command every 10 minutes to keep the build result set as small as possible, and now Continuum is responding much faster than before. If you are interested, please check my latest work from the following Subversion repository:

• https://t.motd.kr/repo/svn/continuum-tools/trunk

Ant2IDE generates Eclipse (or other IDE-specific) project files with proper classpath and source folder settings from Ant build.xml automatically.

I wrote ant2eclipse long time ago with my crude shell script skill to generate Eclipse project files from an Ant build.xml file.

In Ant2IDE, I extended the idea so that it works in a more elegant way using the BuildListener interface. The usage is pretty simple:

1. Add ant2ide.jar to the classpath:

   export CLASSPATH="/usr/local/libexec/ant2ide.jar:$CLASSPATH"

2. Change the working directory to the project home:

   cd /home/trustin/workspace/myAntProject

3. Clean the build

   ant clean

4. Run ant with the -listener option and appropriate task(s):

   ant -listener net.gleamynode.ant2ide.EclipseProjectGenerator compiile-main compile-test

You might prefer to use the following simple shell script:

#!/bin/sh
# Path: /usr/local/bin/ant2eclipse
export CLASSPATH="$CLASSPATH:/usr/local/libexec/ant2ide/ant2ide.jar"
ant -listener net.gleamynode.ant2ide.EclipseProjectGenerator "$@"

How it works

How does Ant2IDE generate the Eclipse project files? It listens to the build events fired by Ant and records the source and destination directory of the javac tasks into its internal data structure. Once build is completed successfully, Ant2IDE processes the recorded information to generate IDE-specific project files. It’s very simple but it works much better than analyzing build.xml directly or creating a new Java project from an Eclipse workbench.

Caveats

Of course, Ant2IDE is not a silver bullet – there’s some limitation in this approach.

First, you can’t get the correct build information unless you provide a proper Ant target. For example, clean target will never help AntIDE generate the project files. You should specify the target that compiles all source code, such as build-all or all, test-all.

Second, it doesn’t add all resource directories automatically. You have to add them manually for most cases. There’s no way to determine exactly whether a copy task copies resource files for now. One exception is when your project has a directory layout which is similar to that of Maven 2 project; Ant2IDE looks for a resources directory when the name of the source code directory is java, and add the resources directory to the source path automatically.

Third, Eclipse JDT is the only IDE that Ant2IDE supports at this moment. It’s designed to support other IDEs such as NetBeans and IntelliJ, but I don’t use them these days. Any contribution would be great.

Changelog

• Nov 19, 2008 – Added auto-detection of resources directory
• Nov 14, 2008 – Initial implementation

Use RoxTerm instead – 'roxterm --tab' opens a new tab in an existing terminal window, with no hack described here.

GNOME terminal has great support for tabbed terminal sessions. You can simply open a new tab by pressing CTRL+SHIFT+T and it’s very convenient.

However, it seems like there’s no straightforward way to ask gnome-terminal command to reuse an existing window and add a new tab there. I tried various options like --tab, but they didn’t work as I expected. I just want to keep only one terminal window in my desktop, but it looks like there’s no command line option that does the job.

So, I wrote a shell script that adds a new tab to an existing GNOME terminal window when there is already a running instance. It also launches a new terminal window if necessary:

#!/bin/bash
# Path: /usr/local/bin/gnome-terminal
if [ "x$*" != "x" ]; then
  /usr/bin/gnome-terminal "$@"
else
  pgrep -u "$USER" gnome-terminal | grep -qv "$"
  if [ "$?" == "0" ]; then
    WID=`xdotool search --class "gnome-terminal" | head -1`
    xdotool windowfocus $WID
    xdotool key ctrl+shift+t
    wmctrl -i -a $WID
  else
    /usr/bin/gnome-terminal
  fi
fi

This script looks for an existing gnome-terminal window, sends CTRL+SHIFT+T key event there, and raises the terminal window. Please note that xdotool and wmctrl are required to run the script. They should be available in most Linux distributions.

It’s just a band-aid solution – I hope I can get rid of this script from my system when the next release of GNOME terminal is out.