I did have some problems sending a report through msn about a build with luntbuild. It turns out that the library used for msn uses an old protocol. There is a jar file in the directory WEB-INF/lib called msnm.jar. You can download a newer version from the following website:
http://sourceforge.net/projects/jmsn/
I downloaded the msnm-lib.tar.gz file, this file contains the jar file msnm.jar. After copying this new jar file over the old one everything works fine.

Now we have a nice message in our msn client. Cool

Yesterday I was reading other blogs and I came across a code coverage product. About 2 years ago I also was looking for a free opensource code coverage tool. It was GroboCodeCoverage that I found. This tool just did not cut it for me. To much effort to get it to work for my kind of architecture, which consits of multiple projects. Each layer has it's own project (web,business,domain,data access). And I ran into performance problems very often. So when I heard about another framework I wanted to give it a try. Since I am using luntbuild as a build manager, I also want to integrate the results into luntbuild. The integration must be simular to the junit integration.

Now what is that tool I am talking about? I am talking about cobertura. Via the faq of cobertura I also found emma. I choose Cobertura for the easy installation and use, but most of all for the way the reports are created. I like them much more than the reports of emma. I the future I do want to have a look at emma to see if performance is different for the tools.

Sorry for the long introduction, now we are going to install and use cobertura. First I installed version 1.4, but I ran into problems while using it with multiple components into one project. You have to merge the result files of the coverage measurements. This only worked correct in the latest greatest cvs version.

Have a look at another blog item of mine that gives you a better option of presenting the link to the reports : extending luntbuild with cobertura reports


cvs -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/cobertura login
(Just hit enter for the password)
cvs -z3 -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/cobertura checkout -P cobertura

cd into the cobertura directory and run ant with the coverage jar options

ant coverage jar

This creates a cobertura.jar file.

Before we can use ant we need to add some jars to the ant lib folder. These jars come with the cobertura sources.
jakarta-oro-2.0.8.jar asm-2.0.jar log4j-1.2.9.jar java-getopt-1.0.9.jar ccl.jar javancss.jar

Now we need to configure our ant build scripts so that the instrumentation (changing the byte code of the classes) takes place. After that we need to run the unit test with the correct classpath and finally run the reports task of cobertura. How does this look in our build script:


<taskdef classpath="cobertura.jar" resource="tasks.properties" />

<target name="compiletest" description="Compile all test code, and instrument classes for coverage">
... omitted code to compile test cases for clarity ...

  <cobertura-instrument todir="${dir.component.coverage.instrument}">
    <ignore regex="util.*" />
    <fileset dir="${dir.component.build}">
      <exclude name="**/Test*"/>
      <include name="**/*.class"/>
    </fileset>
  </cobertura-instrument>

  <copy todir="${dir.component.coverage.src}">
    <fileset dir="${dir.component.src.java}" includes="**/*.java" />
  </copy>
</target>

This block of code instruments all classes in the build folder except for the test cases, in the end the sources are copied to a central directory. The sources are used to show you the lines that have test coverage. This is a work around, a next release will enable you to have multiple source directories in the report task.

The classes are instrumented, now we must put them on the unit test classpath, we also need the cobertura.jar file at runtime on the classpath.

<junit printsummary="on" fork="true" forkmode="once" haltonfailure="false" failureproperty="test.failed" showoutput="true">
  <sysproperty key="net.sourceforge.cobertura.datafile" file="${basedir}/cobertura.ser" />
  <classpath>
    <pathelement path="${dir.component.coverage.instrument}"/>
    <path refid="project.classpath"/>
    <pathelement path="${compiler.classpath}"/>
    <pathelement path="${dir.component.build}"/>
    <fileset dir="${dir.component.lib}">
      <include name="*.jar"/>
    </fileset>
  </classpath>
  <formatter type="xml" usefile="true"/>

  <batchtest todir="${dir.project.junit.report}">
    <fileset dir="${dir.component.src.test}">
      <include name="**/Test*.java"/>
    </fileset>
  </batchtest>
</junit>

Important in this code are the sysproperty tag, this helps the unit test to find the just data file. Another important thing is to put the instrumented classes on the classpath before the normal classes. The directory for instrumented classes is obtained via the property ${dir.component.coverage.instrument}. The cobertura.jar file is in the lib folder ${dir.project.lib} that is added to the classpath via the project.classpath.

After all unit tests have been executed we have cobertura.ser files for all components. We first need to make one data file and then run reports on this merged datafile. This is done by the following piece of script.

<target name="test" depends="distribution,runtests" description="Runs the junit report">

... omitted code to execute junitreport for clarity ...
  <cobertura-merge>
    <fileset dir="${basedir}/">
      <include name="*/cobertura.ser"/>
    </fileset>
  </cobertura-merge>
  <cobertura-report srcdir="${dir.project.coverage.src}" destdir="${coverageHtmlReportDir}"/>
</target>

Important in this code is the merge tag, this looks at all subfolders for cobertura.ser files and merges these into a new cobertura.ser file. Another important part for luntbuild integration is the parameter ${coverageHtmlReportDir}. The value for this parameter is provided by luntbuild and gives the location for storing the report files.

The next image gives an example of the report that is created for my sample application:
[img]/images/ScreenshotCoverageReport.png[/img]
Now we want those coverage reports in luntbuild. For starter, this can propobly be done different in the meaning of correct. What I have done is a hack, but for me it works. Have a look at another blogitem of mine for a better way of integrating the cobertura reports and luntbuild. Actually there is two things we should do:
1. Place the report files in the correct directory, this is done by ant but we need to pass the right parameter plus value.
2. Show a link on the website that directs to the coverage report.

Lets start with the first item, this can be done by configuring the builder. Open your luntbuild project configuration. Go to the builder tab and put an extra variable in the Build properties box:

coverageHtmlReportDir="${build.publishDir}/coverage_html_report"

This parameter is used by ant to find the luntbuil publish directory.


Now we want to add a link to the luntbuild Build view page. This done by adding some lines to the file LUNTBUILD_HOME/WEB-INF/BuildViewer.html

... more here ...
<td width="10%" align="center" class="buildTitleRight">
  <span jwcid="@Conditional" condition="ognl:junitHtmlReport!=null">
    <span jwcid="@GenericLink" href="ognl:'statefulPublish/coverage_html_report/index.html'" title="coverage report">
coverage report
    </span>
  </span>
</td>
<td width="10%" align="center" class="buildTitleRight">
  <span jwcid="@Conditional" condition="ognl:junitHtmlReport!=null">
    <span jwcid="@GenericLink" href="ognl:'statefulPublish/'+ junitHtmlReport" title="junit report">junit report</span>
  </span>
</td>
... more here ...

I copied the td for junit, what I wanted was an extra parameter coverageHtmlReport. I did not figure out how to do just that. The following image shows what it is looking like.


In reply to a question in the comments I have added the complete build.xml files as well. The project I am using cobertura for has modular design. Therefore there is one main build.xml file that is the starting point. There is another build.xml file that contains the generic targets used by the modules. Finally every module has it's own build.xml file.
build-main.xml

build-targets.xml

build.xml

Today I had a very positive experience with google cache. I am so glad I remembered its existence. I was working on this blog and needed some material from an older post. Then I did something very stupid, copied the new post over the old one, and lost everything. Hmm, no backup files or what so ever. Then I realised google had cached pages. So I did a google search, found the page I was looking for and luckily could restore the complete page, well oke, except for formatting issues.

So again, thank you google.

For a project I had a look at the apache commons-pool project.. Pooling consists of two parts that enable you to separate the creation and destroying of objects and the pooling of objects:
1. An object pool - Obtains objects from the pool and returns objects to the pool.
2. An Object factory - This means it creates new objects, destroys objects, checks the status of objects, etc.

The commons-pool project provides two sets of interfaces for these two parts, each containing a standard interface and an interface with a key:

public interface ObjectPool {
  Object borrowObject();
  void returnObject(Object borrowed);
}

public interface KeyedObjectPool {
   Object borrowObject(Object key);
  void returnObject(Object key, Object borrowed);
}

public interface PoolableObjectFactory {
  Object makeObject();
  void activateObject(Object obj);
  void passivateObject(Object obj);
  boolean validateObject(Object obj);
  void destroyObject(Object obj);
}

public interface KeyedPoolableObjectFactory {
  Object makeObject(Object key);
  void activateObject(Object key, Object obj);
  void passivateObject(Object key, Object obj);
  boolean validateObject(Object key, Object obj);
  void destroyObject(Object key, Object obj);
}

The framework also provides some standard implementations for these interfaces. These are the base implementations, all abstract classes with minimal implementation code:
BaseObjectPool
BaseKeyedObjectPool
BasePoolableObjectFactory
BaseKeyedPoolableObjectFactory

These are all abstract classes that you should extend when writing your own ObjectPools and PoolableObjectFactories. There are also a number of these implementations available. They all extend the base editions.

• GenericObjectPool : ObjectPool implementation with a FIFO (First In First Out) behavior. This queue like behavior makes sure each object is regularly used. (helps preventing time-outs)


• StackObjectPool : ObjectPool implementation with a LIFO (Last In First Out) behavior.


• SoftReferenceObjectPool : ObjectPool implementation with a LIFO (Last In First Out) behavior. Additionally this pool wraps each object in a SoftReference allowing the garbage collector to remove them in response to memory demand.


• GenericKeyedObjectPool : ObjectPool implementation with a FIFO (First In First Out) behavior.


• StackKeyedObjectPool : ObjectPool implementation with a LIFO (Last In First Out) behavior.

Now lets have a look at these implementations, first the BaseObjectPool and the GenericObjectPool. The base is an abstract class and gives a default implementation for a few methods. The GenericObjectPool extends from the BaseObjectPool and is a class that can best be extended for your own object pool. The BaseObjectPool needs a PooledObjectFactory to function, this factory is used to obtain new objects, destroy objects, validate objects and some other actions. The GenericObjectPool also provides a Config subclass that helps to set the available configurations parameters. Have a look at the excellent java doc for detailed description of methods and fields. GenericObjectPool and
PoolableObjectFactory

Time for a very easy example that shows the most basic use of the pooling mechanism:
We need a factory : SamplePoolableObjectFactory implements PoolableObjectFactory
and an object pool : SampleObjectPool extends GenericObjectPool

The only thing that the different methods do is logging, oke except for the makeObject and destroyObject. The make creates a new object and the destroy sets it to null.

Then we make a runnable application that obtains and returns a number of objects from the pool.

public class RunApp {

  public static void main(String args) throws Exception {
    System.out.println("Starting app");
    SamplePoolableObjectFactory factory = new SamplePoolableObjectFactory();
    SampleObjectPool pool = new SampleObjectPool(factory);

    Object obj1 = pool.borrowObject();
    Object obj2 = pool.borrowObject();

    pool.returnObject(obj1);

    Object obj3 = pool.borrowObject();

    pool.returnObject(obj2);
    pool.returnObject(obj3);
    System.out.println("Closing app");
  }
}

From the code you can see we obtain two objects from the pool, then we return one of the objects and get another one. We expect that the third object is the same as the first. By the way, the numbers in the log messages are hashcodes. The result is:

Starting app
New pool created with factory ...
Borrow an object ...
Make object ...24807699
Activate object ...24807699
Borrow an object ...
Make object ...19608436
Activate object ...19608436
Return an object ...
Passivate object ...24807699
Borrow an object ...
Activate object ...24807699
Return an object ...
Passivate object ...19608436
Return an object ...
Passivate object ...24807699
Closing app

This is as expected.

Hope this helps creating your own Object Pool implementation. You can download the eclipse project here

I did have a blog entry about installing linux ob my laptop. Now fedora core 4 is released and there were some issues with my last installation. Therefore I had to do it again. After reading my own post i did not find it very intuitive. Therefore I make another post with only the commands that I used to get wireless to work.

# cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/madwifi co madwifi

# yum install sharutils
# export COPTS="$COPTS -DSOFTLED"
# make
# make install

Create the following file:
/etc/sysconfig/network-scripts/ifcfg-ath0

# Atheros Communications, Inc. AR5212 802.11abg NIC
DEVICE=ath0
ONBOOT=no
BOOTPROTO=dhcp
USERCTL=yes
PEERDNS=yes
TYPE=Wireless
ESSID=
CHANNEL=1
MODE=Managed
RATE=Auto

Then add the following line to /etc/modprobe.conf:

alias ath0 ath_pci

Now open the network settings:
Desktop > System settings > Network

Edit the wireless device and connect to your network

• check the 'activate device when system starts' option in the general tab


• Wireless tab, specify a SSID an the key.


• Add a hostname to the dnstab, this prevents gnome from giving a strange message about adding a name to the hosts file.

Activate the wireless network card and save the configuration.

That did the trick for me.

If you have improvements or just comments, please feel free to add a comment to this blog item.

Today I have installed fedora core 4 on my ibm laptop. Most was working fine out of the box. I am having some problems finding utlities, but the command line works fine.

I was having some issues with my wireless network, but these are resolved now. Since this can be an issue for others as well I do want to share my experience with you.

The first thing you need to do is find a good website, oke try this one for instance:
http://www.niemueller.de/wiki/?ThinkpadT41pWithFC3

When following this guideline there was an issue with uudecode. This is not installed per default in fedora. Therefore you need to install these libraries. I found the right command on another website:

yum install sharutils

the website is: (beware, tough to read for some of us)
http://wiki.nothing.sh/page/ThinkPad/Fedora%20Core%204

Then you probably know that your laptop has a small light for wireless activity. This can be turned on by issuing the following command before you run make:

export COPTS="$COPTS -DSOFTLED"

Found that on the website:
http://vsharma.net/thinkpad-t41p-fedora-core1/

Thats all, run make and make install and connect to your network.

Today I started experimenting with dynamic mock objects. I am trying out the http://www.easymock.org library. It is not really hard to start using it. Oke, now tell me what it does.

Easy mock takes an interface and creates an object. Then you configure this object. Tell it what methods will be called and how to respond to these methods. In the end you can verify if everything went like you expected.

Let's have an example:
First we need an interface

public interface EntryDao {
  public Entry findEntry(int entryId);
  public Collection findLastEntries(int numberOfEntries);
  public void create(Entry entry);
}

Then we need to have a class that uses an implementation of this interface.

public class BlogServiceImpl implements BlogService {
  private EntryDao entryDao;
  public BlogPosting getLastItem() {
    Collection foundEntries = this.entryDao.findLastEntries(1);
    return (BlogPosting) foundEntries.iterator().next();
  }
  public void setEntryDao(EntryDao entryDao) {
    this.entryDao = entryDao;
  }
}

Now we want to test this class, but we do not have an implementation for the EntryDao interface. Thats where EasyMock comes in. We will create a unit test that uses the easymock library to create a mock object for the EntryDao interface, tell it what method calls to expect and what to return. The complete test class looks like this.

public class TestBlogServiceImpl extends TestCase {
  private BlogService blogService;
  private MockControl entryDaoControl;

  private EntryDao entryDao;


  public void setUp() {
  entryDaoControl = MockControl.createControl(EntryDao.class);
    entryDao = (EntryDao)entryDaoControl.getMock();

    BlogServiceImpl blogServiceImpl = new BlogServiceImpl();
    blogServiceImpl.setEntryDao(entryDao);
    this.blogService = blogServiceImpl;
  }

  public void testGetLastItem() {
    entryDao.findLastEntries(1);
    Entry lastEntry = new Entry();
    lastEntry.setEntryId(1);
    Collection foundEntries = new ArrayList();
    foundEntries.add(lastEntry);
    entryDaoControl.setReturnValue(foundEntries);
    entryDaoControl.replay();

    BlogPosting lastPost = blogService.getLastItem();
    assertNotNull("Last Item should not be null",lastPost);
    assertEquals("The obtained last post is not the expected post",
      lastEntry,lastPost);
    entryDaoControl.verify();
  }
}

Within the setUp method we create the MockControl object and obtain a mock object from the control.

entryDaoControl = MockControl.createControl(EntryDao.class);
entryDao = (EntryDao)entryDaoControl.getMock();

Then in the testGetLastItem method, we start telling the mock object what method calls to expect by really calling them:

entryDao.findLastEntries(1);

After that we tell the mock object the value or object to return when the method is called.

entryDaoControl.setReturnValue(foundEntries);

By calling the replay method we prepare the mock object. Then we start the real test for the method under test and evaluate the returned values.

The final call to the mock controller is the validate method. This checks if the expected calls are made to the mock objects methods.

More information can be found on the easymock website : http://www.easymock.org/Documentation.html

I am working on a sample application with the spring framework. Within the project I am also using easymock, if I encounter problems or nice solutions I will get back on it in this blog.

I made through the complete book. An interesting but rather long read it was. First some general remarks. I did like the book, well at least the first 100 pages. Then to me it was more of the same. The satirical songs and stories began to iritate me. The number of references to other parts of the book are way to much as well. Nevertheless, I did like the book, some conclusions are a bit harsh. The book gives some refactorings to the XP process to make it better. The best thing is that the book makes you think about your own process while developing software. Should you read this book? Tough question, if you have the time I would most certainly read it. If you do not have the time, you can allways jump to the conclusions of most of the chapters.

The book consists of a number of parts each containing a number of chapters.

Part I
This section gives a short introduction about XP. It discusses the values of XP, the 12 practices, the roles and the activities.

I think the best lines that tell you how the writers think about the book are these.

"XP is a methodology created by programmers who are sick of management telling them that they can no longer just code, but they must follow a formal methodology. XP's main tenets are all very programmer=centric and often fail to consider the larger scope of a software development project."

The next chapter discusses the famous XP project C3. Some of the project members were Kent Beck, Ron Jeffries, Martin Fowler, Chet Hendrickson and Don Wells. There are a lot of quotes and references to the wiki website and to other resources on the web. This way you can create your own opinion. The discussion whether the project is a success or not is hard. It did come to results within 11 months that are still used. Other projects trying the same did not succeed at all. However 4 years of hard work did not nearly reach the state of providing the complete system. I guess Xp is hard to be used in a project that takes longer than about 3-4 months. But the biggest problem is the lack of design and specifications. I believe in the goal oriented design and the use of personas. See the book The inmates are running the asylum.

A few of the most interesting links are:
http://c2.com/cgi/wiki?CthreeProjectTerminated
http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation

Chapter 3, the final chapter of this part introduces the twelve serpents and the circle of snakes. What they want to tell you is that every snake is made safe by the following snake, if one snake is let loose, the circle brakes and all snakes are on the run. The remainder of the book will discuss the snakes and refactorings that makes the process safer. The snakes are:

• No detailed written requirements.


• Emergent design


• Constant Refactoring


• Unit tests


• Pair programming


• Collective ownership


• on site customer representative

I'll give an example by one of the snakes. Emergent design means that very little time is spent designing the system before coding begins. The overall design and architecture will morph many times in the course of the project. But the lack of significant upfront design is considered "safe" because the code is being constantly refactored. So if refactoring fails ....

They make it pretty obvious they do like some concepts, but you need to refactor them for your project.

One thing that made me laugh in the book was there way of discussing the 5 o'clock go home, anythin not done, throw it away XP practise. The following satirical quote makes it clear.

Child : "What did you do today, Daddy?"
Father : "I tossed out my code and went home clean. And tomorrow I intend to pair program and stare at someone else typing."


Part II
This part is about the social aspect of XP. One of the things that remains in my head when reading this chapter is bout the blame when the project fails. Within XP it is the people who are to blame, since the process is good. If you think bad about the process, you are in fear.

Onsite customer
The red line within this chapter is that being a customer is hard. Youe need to provide the requirements on story cards and prioritize them. You need to write runnable test scripts. When the project becomes to large you need to have a team from the customer. Because there are no written requirements the customers needs to talk with one voice. The solution is to have a customer available to an analist. The analist takes care of the requirements by analysing the customers needs and goals.

Pair programming
Pair programming can be helful when looking at tough problems. Pair programming with 100% of production code is extreme. People just cannot handle it being in one persons space with two persons all the time. On top of that pair programming is not the same as peer review while both are targetted at getting better code.

Oral documentation
One of the things programmers hate most is writing documentation. That is possibly the reason why so much programmers love XP. I think the following quote from the book touches the heart of the problem.
Fowlers quote highlights the fact that design documents in XP are mostly transitory. This contrasts greatly with the notion of design documents in, say RUP, which calls all items of ducomentation artifacts (which suggest documents that are long-lived and may be dug up several years later). Although this notion may at first seem absurd, the maintenance team who actually do need to dig up that documentation several years later will offer a prayer of thanks to the previous team members for their forward thinking.

Within RUP it is important to decided what to document. Ask yourself the questions: Who is going to use it? Who is going to miss it?

It does not take courage to stop writing documentation. It takes courage to take a product into maintenance without documentation.

Design after first testing
No BDUF - Big Design Up Front, this probably one of the biggest issues the writers of the book have with XP. I strongly believe that Design upfront is very important. This does not mean that writing tests upfront is wrong. Writing unit tests upfront does make you think about what to write before you write it. This also valid for design and analysis. Therefore test driven development is important, but equivalent to design upfront. In fact they complement each other. The chapters contains the following lines by David Van Der Klauw which I find interesting:

My concept of bug finding is something like this : A programmer should find 9/10 bugs before check-in, the automatic tests should find 9/10 remaining bugs before hand over to QA, QA should find 9/10 before handover to customers who will again find 9/10 the other 1/10 will never be found. Therefore the customer only sees 1 in a 1000 bugs

Morale, if you release to soon to the customer, he sees to many bugs and looses interest in the product.

Constant refactoring after programming
Refactoring is not bad, that is clear. However, constant refactoring code that works fine is not allways good. Why keep changing code just because it smells bad. So use refactoring when changes are necessary for requirements changes, bugs, or after a code review, but know when to stop.


Another thing about refactoring is UserInterface refactoring. Especially within XP, the users get to use the product very soon. But refactoring the UI makes the users look for functionality every release. When the users get to use the product soon, you also must maintain the live data. Refactoring also leads to a database refactor. Be very carefull with production data. Make solid migration plans.

User stories and acceptance tests
With all requirements the analysis is very important. Within XP User stories are used. These are very short descriptions of what a user wants to do with the system. Comparing these to use case (RUP) is obvious. What is missing with user stories is the failure conditions and actions, or the rainy-day scenarios. The step between the user stories and real code is large. You need to do requirements as well as design. The emphasize within XP is on Code. If the user story is not clear, use the customer representative to make things clear. Problem is this extra information is only documented in the code. Refactoring and you can loose requirements. No problem, if the customer representative does not miss it with his tests then it was probably not important. Another part that is hard to graps within user stories, especially since the customer should write these are the non functional requirements (FURPS+)

Part III, IV and V
To be honest, this is the moment where I started to loose interest. More of the same, sometimes in other words, there are a few statements that I want to mention and some good references.

Interesting subject about fixed scope, time, budget. This leaves just one parameter open and thats quality. You cannot make them all fixed.

Another thing that struck me it the use of frameworks. The book states this is not done within XP since you will never find a user story that tells you to use a framework. I cannot image this is true. One of the reasons I think that this book is to extreme itself.

They are also talking about Emergent Architecture, this is achieved via evolutionary prototyping that ends up as production code. Looking at RUP for instance, you have early prototyping, the code is not used in the production code. Usually this prototyping is quick en dirty, just to see that it works.

That's about it for the book. Hope this helps. I will use the gained knowledge to write down some theory in the wiki. I will close this review with a last quote, that applies to XP, but to some extend to the book as well.

I believe that a major flaw in XP is that it takes things to an extreme. I believe in doing things is moderation and trying to optimize the value by trading off one factor against another. In life, I fin that rarely is the optimum achieved at some extreme point.

Today I have been working on the security module of the wiki. For now I have added security to the wiki. This is a cookbook module and it turned out that is was fairly easy to configure.

http://www.pmwiki.org/wiki/Cookbook/UserAuth

I really like this wiki software, custmizationg is easy and the documentation is thourough. I also did an upgrade of the wiki software, which worked liked a charme following the documentation.

If anyone feels like contributing to the wiki, please drop us an email and tell us what you want to do and a little bit about your background. We will add this information to the wiki profiles.

Yesterday was a Continuous Integration day. I am pretty familiar with tools like apache ant and Cruisecontrol. But these tools just don't cut it. I don't like the website that you use with cruisecontrol and Maven is becoming more popular every day. Then I read that Luntbuild had a new release. I have been experimenting with Luntbuild in the past and thought about giving it another go.

First I needed to install luntbuild. There is an install guideline for dummies on the wiki. According to the guideline I installed tomcat (version 4.1.31), that is really not to hard. Then you should use the installer for luntbuild (version 1.2), this isn't working on my windows Xp. There is an issue with the script, uses a jar command that is not working out of the box, probably a hole in my knowledge. Then I downloaded the zipped version, altered the web.xml and applicationContext.xml files. I replaced some placeholders with real values

web.xml - installDir, added the real path to the installation directory of luntbuild
applicationContext.xml - inMemoryAuthenticationDAO, changed the placeholder of the password for luntbuild user

For simplicity I used winzip to create the war file from the luntbuild/web directory. Then go to the tomcat manager website and upload the warfile. Then everything should be working and you should be able to logon to the luntbuild website.

Now what? I have a website then can manage builds. I think I need a build first and to create a build you first need a project. The last few days I have been experimenting with springframework. In order to store the results I created a project at tigris.org, drop me an email if you want to have access to the website. This website uses Subversion as a Repository.

Oke, now I have a project and I need a build that luntbuild can execute. I did have a look at maven, but I feel more confortable with ant. I created the following build.xml file.

<project name="SpringSample" default="compile" basedir=".">
  <property name="dir.src" value="src"/>
  <property name="dir.build" value="build" />
  <property name="dir.dist" value="dist" />
  <property name="dir.lib" value="lib"/>
  <property name="dir.test" value="test"/>
  <property name="build.junitHtmlReportDir" value="report"/>

  <target name="prepare" depends="clean" description="Create output directories">
    <mkdir dir="${dir.build}"/>
    <mkdir dir="${dir.dist}"/>
    <mkdir dir="${build.junitHtmlReportDir}"/>
  </target>

  <target name="clean" description="Remove all generated files">
    <delete dir="${dir.build}"/>
    <delete dir="${dir.dist}"/>
    <delete dir="${build.junitHtmlReportDir}"/>
  </target>

  <target name="compile" depends="prepare" description="Compile all source code">
    <javac srcdir="${dir.src}" destdir="${dir.build}">
      <classpath>
        <fileset dir="${dir.lib}">
          <include name="*.jar"/>
        </fileset>
      </classpath>
    </javac>
  </target>

  <target name="jar" depends="compile" description="Generates the SpringSample.jar in the 'dist' directory">
    <jar jarfile="${dir.dist}/SpringSample.jar" basedir="${dir.build}"/>
  </target>

  <target name="compiletest" description="Compile all test code">
    <javac srcdir="${dir.test}" destdir="${dir.build}">
      <classpath>
        <pathelement path="${dir.build}"/>
        <fileset dir="${dir.lib}">
          <include name="*.jar"/>
        </fileset>
      </classpath>
    </javac>
  </target>

  <target name="test" depends="compile,compiletest" description="Runs all unit tests">
    <junit printsummary="on" fork="false" haltonfailure="false" failureproperty="test.failed" showoutput="true">
      <classpath>
        <pathelement path="${dir.build}"/>
        <fileset dir="${dir.lib}">
          <include name="*.jar"/>
        </fileset>
      </classpath>
    <formatter type="xml" usefile="true"/>

    <batchtest todir="${build.junitHtmlReportDir}">
      <fileset dir="${dir.test}">
        <include name="**/Test*.java"/>
        </fileset>
      </batchtest>
    </junit>

    <junitreport todir="${build.junitHtmlReportDir}">
      <fileset dir="${build.junitHtmlReportDir}">
        <include name="TEST-*.xml"/>
      </fileset>
      <report format="frames" todir="${junitHtmlReportDir}"/>
    </junitreport>
  </target>
</project>

I am not going to explain it here, there are good resources to find on the web about ant. The hardest part for me to find (oke, it was time to go to bed) was the integration with junit and luntbuild. Things that are hard to find are often easy to do. Luntbuild can provide parameter values to the ant script. One of these parameters defined in the project is : junitHtmlReportDir. This parameter is used in the report tag to copy the results to.
<report format="frames" todir="${junitHtmlReportDir}"/>

Luntbuild can be used to send emails with information about the build. Another fine option is to send messages to a jabber account or an msn messenger. To bad I can not get the messenger part to work. Maybe this will go as is should in the next few days.

There is a good manual for luntbuild on theire website.

I like luntbuild, it is fairly easy to use, I do need to do some work on reports like cruisecontrol has though. The user interface is very nice and does what it should.