1. (1) Code Walkthrough robocode-pmj-dacruzer Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii Honolulu HI 96822

2. (2) robocode-pmj-dacruzer: An example Ant-based build system Implements a pretty lame Robocode robot. Not very interesting. It’s the build system that’s interesting: Provides a template - Easy to adapt to your own projects. Integrates third-party build tools - Checkstyle, PMD, FindBugs, etc. Is modular and extensible - You can grow or shrink it to your needs. Well suited to build automation and project hosting: - Continuous integration (Hudson) Uses Ivy to download/install/manage third-party libraries. Result is Maven-ish, but without the “black box” If you want to change something, it’s just Ant code.

3. (3) Top-level directory contents build.xml top-level build file. *.build.xml “module” build files, generally one per tool. src/ the system source files lib/ library files: maintained by Ivy. build/ derived files: generated by build process

4. (4) Build operations compile compile system jar create jar file junit run junit tests javadoc build javadoc docs clean delete build dir. dist create zip dist file. checkstyle analyze source code findbugs analyze byte code pmd analyze source code sclc compute size of system emma compute coverage of test cases. (Others to be added later in semester!)

5. (5) Build System Scalability Issues Modularity: putting all targets in one build.xml file creates a very large build.xml file that is difficult to understand and maintain. Incrementality: you may not want to require all developers to have to install every possible third party tool. Coupling: dependencies between target and property definitions should be minimal and easily visible.

6. (6) Build system architecture build.xml pmd.build.xml findbugs.build.xml dist.build.xml checkstyle.build.xml javadoc.build.xml sclc.build.xml *.build.xml build.xml contains most project- specific definitions. *.build.xml files import the build.xml file and provide an implementation of a single extension. common.build.xml boilerplate code

7. (7) build.xml build.xml provides most (but unfortunately not all) of the project-specific definitions: version number dependency libraries project name etc. Most other *.build.xml files can be used with little to no changes. Typical exceptions: junit.build.xml, emma.build.xml, jar.build.xml

8. (8) *.build.xml responsibilities Implements support for a single tool/function: Checkstyle, Jar, JavaDoc, PMD, Distribution, etc. Typical tasks (assume a tool called 'foo'): Download foo using Ivy, install in lib/foo Download a configuration file for foo, store in lib/configfiles. Provide three standard tasks: - foo.tool: runs foo tool, generates data. - foo.report: creates HTML file. - foo: runs foo.tool and foo.report. Make 'foo' the default task.

9. (9) Key Ant Concepts and Tasks (for now) Concepts: Properties Targets Tasks Paths Dependent targets build/, bin/, lib/ directory hierarchies Tasks: