Stable Builds: Using Ant and QA Tools
| Posted on Friday, September 19, 2008 |
0
commentsAdd comments |
“Even the ant has his bite.” — Turkish Proverb
I doubt the Turks had Apache’s Ant in mind when they popularized this proverb. But, I definitely felt Ant’s bite when working through the tasks outlined in a recent software engineering assignment. The assignment consisted of three tasks, each task comprised of several steps—you know, in that way college assignments seem to be constructed.
1, 2... What Do I Do?
Okay, okay, so maybe it wasn’t as bad as being bit by a bullet ant, but getting through the first task definitely stung a little. The first step of the initial assignment task was to install Ant along with several Quality Assurance (QA) tools—JUnit, PMD, FindBugs, and Checkstyle. So, first things first, install Ant... I decompressed the zip file, moved the files to the appropriate directory location, and then tried to build Ant. But, several failed attempts to build Ant led me to peruse the manual (%ANT_HOME%\docs\manual\install.html). I followed the instructions under Setup and Windows and OS/2. But still Ant failed to build successfully. I needed a better clue. I needed to know what to do.
3, 4... Chores Galore
That initial sting could have been avoided just a bit, if I had just read the Ant build error messages closer. My Ant build had issues, it first needed JUnit. Okay, not a problem. Just install the QA tools first. Checkstyle, FindBugs, and PMD all installed easy enough. (Note: Some decompressed folders added an extra root folder that I had to remove in order for the QA tool to build correctly.) After that, a quick trip to the Windows Control Panel > System > Advanced System Settings > Environment Variables dialog to create or edit the system variables:
• ANT_HOME = C:\dev-tools\ant-1.7.1• CHECKSTYLE_HOME = C:\dev-tools\checkstyle-5.0-beta01• CLASSPATH = .;• FINDBUGS_HOME = C:\dev-tools\findbugs-1.3.5• JUNIT_HOME = C:\dev-tools\junit4.5• Path = Added %ANT_HOME%\bin;• PMD_HOME = C:\dev-tools\pmd-bin-4.2.3
JUnit took a little work to get a successful build. After looking under Installation in the JUnit manual (%JUNIT_HOME%\README.html), I entered the commands there and it finally worked. Now, I was ready to attempt another Ant build. It was a successful build. I downloaded the necessary assignment files, and completed the remaining chores in the first task.
5, 6... Stack Gets Fixed
The second task was basically a repeat of the first (minus the lengthy installation step). It required making a copy of the downloaded assignment files, a simple Stack implementation riddled with a handful of errors. These errors were purposely left in the source files, as the objective of the assignment was to become familiar with using QA tools to improve the stability of Java projects.
The third and final task picked up here by requiring the errors identified from by the various QA tools be corrected. Once all the errors had been appropriately addressed, the corrected files (compressed) were to be posted to the web for review. My compressed, corrected Stack implementation is available here:
• Stack-Reeves-6.0.919.zip
7, 8... E-LIM-I-NATE!
The biggest issue I had with using the QA tools was that I thought I could first run all of them, then go back and look at the errors identified by each. Unfortunately, running some QA tools causes the
Most of the errors were simple to eliminate—move a
9, 10... Fini. Fin.
Overall, I am impressed with Ant. While it may have been challenging to get set up initially, its power become evident quickly on during the build processes. It is easy to see what the lowly ant and Apache’s Ant have in common: each is a tiny implementation (one biological, one digital) that does much more than seems it should be capable of doing. Nature’s ant can lift 100 times its body weight, whereas Apache’s Ant can verify Java projects containing 100 times (and more) lines than in the build.xml files. In addition, being my first experience with these QA tools, I am truly amazed. It is great to have a set of standards—very close to ones I have been using personally for several years, which can be verified against so simply and comprehensively to create stable project builds.
1, 2... What Do I Do?
Okay, okay, so maybe it wasn’t as bad as being bit by a bullet ant, but getting through the first task definitely stung a little. The first step of the initial assignment task was to install Ant along with several Quality Assurance (QA) tools—JUnit, PMD, FindBugs, and Checkstyle. So, first things first, install Ant... I decompressed the zip file, moved the files to the appropriate directory location, and then tried to build Ant. But, several failed attempts to build Ant led me to peruse the manual (%ANT_HOME%\docs\manual\install.html). I followed the instructions under Setup and Windows and OS/2. But still Ant failed to build successfully. I needed a better clue. I needed to know what to do.
3, 4... Chores Galore
That initial sting could have been avoided just a bit, if I had just read the Ant build error messages closer. My Ant build had issues, it first needed JUnit. Okay, not a problem. Just install the QA tools first. Checkstyle, FindBugs, and PMD all installed easy enough. (Note: Some decompressed folders added an extra root folder that I had to remove in order for the QA tool to build correctly.) After that, a quick trip to the Windows Control Panel > System > Advanced System Settings > Environment Variables dialog to create or edit the system variables:
• ANT_HOME = C:\dev-tools\ant-1.7.1• CHECKSTYLE_HOME = C:\dev-tools\checkstyle-5.0-beta01• CLASSPATH = .;• FINDBUGS_HOME = C:\dev-tools\findbugs-1.3.5• JUNIT_HOME = C:\dev-tools\junit4.5• Path = Added %ANT_HOME%\bin;• PMD_HOME = C:\dev-tools\pmd-bin-4.2.3
JUnit took a little work to get a successful build. After looking under Installation in the JUnit manual (%JUNIT_HOME%\README.html), I entered the commands there and it finally worked. Now, I was ready to attempt another Ant build. It was a successful build. I downloaded the necessary assignment files, and completed the remaining chores in the first task.
Revision: Reference to JUnit jar executable file removed from CLASSPATH environment variable. It was indicated this was a suboptimal strategy to maintain the prime directives of software engineering. See my blog JFreeChart: Open Source Charting Solutions for more on prime directives.
5, 6... Stack Gets Fixed
The second task was basically a repeat of the first (minus the lengthy installation step). It required making a copy of the downloaded assignment files, a simple Stack implementation riddled with a handful of errors. These errors were purposely left in the source files, as the objective of the assignment was to become familiar with using QA tools to improve the stability of Java projects.
The third and final task picked up here by requiring the errors identified from by the various QA tools be corrected. Once all the errors had been appropriately addressed, the corrected files (compressed) were to be posted to the web for review. My compressed, corrected Stack implementation is available here:
• Stack-Reeves-6.0.919.zip
7, 8... E-LIM-I-NATE!
The biggest issue I had with using the QA tools was that I thought I could first run all of them, then go back and look at the errors identified by each. Unfortunately, running some QA tools causes the
\build directory to be cleaned and rebuilt when being run. This causes the information from a QA tool run prior to these to be erased. It took me a few times attempting this method, before realizing what was occurring. Once I figured this out, it was just a matter of correcting the errors identified by each QA tool before running the next QA tool.Most of the errors were simple to eliminate—move a
{ to the line above, add final to the declaration of the member fields, and other errors of this ilk. The error that caused me the most frustration was determining what to do with an empty catch block in the testIllegalPop() method in the TestStack class. My first attempts were to throw an EmptyStackException() error, but this caused the build’s JUnit task to fail. Then, I thought I’d try using fail() in the catch block, but that too caused the build’s JUnit task to fail. Finally, I realized the problem. The catch block was actually the valid case of the method. The method is testIllegalPop(), therefore, the try block actually causes the catch block to be invoked. I decided an appropriate way to handle this, since creating a log file was too much overhead for this simple assignment, was to use a System.out.println() command to report the successful catch of the illegal pop attempt to the shell. Eliminating this last error allowed all QA tools to successfully pass the Stack-Reeves implementation. The verify task completed successfully, and I ran the dist task to create the compressed Stack-Reeves files.Revision: “Bogus” was used to describe my use of the
System.out.println() command to resolve the error caused by the empty catch block. Admittedly, this was a bogus solution and used to resolve the issue with minimal effort. Therefore, I have gone back and resolved the issue using a more elegant—and production appropriate—technique as described in the article An early look at JUnit 4.9, 10... Fini. Fin.
Overall, I am impressed with Ant. While it may have been challenging to get set up initially, its power become evident quickly on during the build processes. It is easy to see what the lowly ant and Apache’s Ant have in common: each is a tiny implementation (one biological, one digital) that does much more than seems it should be capable of doing. Nature’s ant can lift 100 times its body weight, whereas Apache’s Ant can verify Java projects containing 100 times (and more) lines than in the build.xml files. In addition, being my first experience with these QA tools, I am truly amazed. It is great to have a set of standards—very close to ones I have been using personally for several years, which can be verified against so simply and comprehensively to create stable project builds.
