1st Kata: Ant Hello World
If there's one thing a software developer will never say goodbye to, it's hello. <\echo\> (imagine that the backslashes aren't there; the same goes for the rest of the tags in this post) is to Ant as "System.out.println()" is to Java. Hello World . . . Hello, My First Ant Build Script. A cinch, a cinch, yes it was.
2nd Kata: Ant Immutable Properties
It's integral that Ant, part dependency manager, should have immutable properties (defined by <\property\> tags), as demonstrated by this kata in which I defined two properties of the same name, assigned them different values (first "1" and then "2"), and printed out the value of the property. Any guesses as to which value was "echoed" to screen?
3rd Kata: Ant Dependencies
Ant's dependency management operates in a very straightforward manner: <\target\> is to be executed only if the "depends" attribute is fulfilled. And if "depends" does not exist, then <\target\> is free to run. In other words: IF "depends" is fulfilled, THEN <\target\> executes. <\project\> is to Ant as "class" is to Java. The attribute of <\project\> called "default" specifies the main <\target\> that a build file should run. This dependency management was demonstrated by implementing the following:
*foo should depend upon bar.
*bar should depend upon baz and elmo in that order.
*baz depends upon qux.
*qux depends upon elmo.
*elmo has no dependencies.
Before running the build script, I had to guess in what order the targets were called, given that "foo" is the default target. I guessed the following: elmo, qux, baz, bar, foo. Right? Yes. Why? foo can't run without bar, and bar can't run without baz and elmo, but baz can't run without qux, which relies on elmo. elmo is the only one without dependencies, so it executes first. qux runs next, allowing baz to run after it. Now that baz and elmo have been executed, bar runs. Lastly, foo runs (it had been waiting on bar this whole time).
The second task was to change the script and make elmo depend upon bar. I had an idea as to what would happen, but I wasn't so sure what would print out. As wonderful as it could ever get, Ant knew exactly what went wrong: circular dependency, since bar ends up depending upon itself.
4th Kata: Hello Ant Compilation
A HelloAnt.java file that prints "Hello Ant" to screen? Easy. Now getting the build file to succeed was all a matter of examining the existing Ant code and modeling my "compile" <\target\> after it. With the use of the <\mkdir\> and <\javac\> tags, I was able to successfully automate the compilation of a Java file.
5th Kata: Hello Ant Execution
This kata was the trickiest so far; I couldn't find an example in the Ant build files I downloaded as part of the Ant package, so I had to search this one up. There were a few unsuccessful executions (using Terminal on a Mac), but I was able to determine that "classname" (name of the Java class, excluding the .class extension) and "classpath" (the location of the Java class file) were the only <\java\> attributes needed. I had success compiling when HelloAnt.java was in the default package, but after moving it to the edu.hawaii.ics314 package, it simply would not compile. Thanks to Jordan Takayama's's blog, I found out that the "classname" attribute should be set to "edu.hawaii.ics314.HelloAnt" and the "classpath" attribute should be set to the "classes" directory. Lastly, this was the first kata that made use of the <\import\> tag (the "compile" build script had to be imported), which is very similar to the #include directive of C/C++.
6th Kata: Hello Ant Documentation
Generating JavaDocs by entering a single command has never been made easier. However, before I could get this to work, I had to create an "overview.html" file (in the "src" folder but outside of the package) and a "package.html" file (in the package). I then made sure that any properties used in the <\javadoc\> tag were specified in my build system before I ran the script file to generate the JavaDocs.
7th Kata: Cleaning Hello Ant
This was pretty straightforward. Again, I modeled my "clean" target after already-existing Ant code. A simple <\delete\> tag did the trick and deletes the "build" directory if "clean" is listed as a dependency.
8th Kata: Packaging Hello Ant
This kata was extremely frustrating at first because I could not for the life of me get my zip file to unzip into a single directory. I tried and tried it my way, trying to ignore existing code in the hopes that it would work for me with a few lines of code. In the end, I had to look at the existing code (from PMJ-DaCruzer's dist.build.xml file) and model my code after that. I learned that it is perhaps impossible to unzip files into a single folder without copying files to a directory within a temporary directory first.
In conclusion, Apache Ant is a very powerful tool, designed to make the distribution of a Java project more user-friendly and efficient. Build systems help us automate distribution, proving to be a bit troublesome when one attempts to go against the flow, but once one learns to adapt to it, the raging river becomes easier to navigate.
No comments:
Post a Comment