If at first you don't succeed...

... you try, try again. And that is exactly what I needed to do this time around. All the steps leading up to creating the distribution took a lot of trial and error. I was able to follow the steps in the powerpoint to create my own project and successfully run ant. Ant is a build tool that allows you to distribute your program to others regardless of platform and other settings. After that, I needed to run quality assurance tests on my code. The checks I needed to run were Checkstyle, PMD, and FindBugs. Between the 3 of them both errors coding standards and logic in the code are shown. Checkstyle reported 6 errors: 1 for not naming my class with a capital letter, 1 for not including the package.html, 2 for not ending the sentence with a period in the JavaDoc, and 2 for not adding the @param for my event functions. But those were all fixed easily enough. PMD and FindBugs didn't report any errors. Setting up JUnit was easy enough, but a silly oversight had me working on it for a while. It turned out I didn't change a package name which I thought I had. Everything else went smoothly.

It was very clear to me very early on how powerful this automated QA was. It was much quicker to find out exactly what the problem was and go back to make some changes. Then it was very fast to run the check again and see if the problem had been solved. One other thing that I realized was that the error messages are very important. Just like how we learned that descriptive comments are very important to understand the code, the messages that errors give are crucial in raising the chances that the problem can be found and fixed. Even with a good error message, it still took me some time to digest what the error was and how to fix it. If the error message had not been descriptive, I may have never found out what the problem was. This tells me that when I write ant code, I really need to be conscious of what error message I display.

You can download my distribution here

*Updated version: here