110 likes | 256 Views
Code Walkthrough robocode-pmj-dacruzer. Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii Honolulu HI 96822. robocode-pmj-dacruzer: An example Ant-based build system. Implements a pretty lame Robocode robot.
E N D
Code Walkthrough robocode-pmj-dacruzer Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii Honolulu HI 96822
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.
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
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!) Build operations
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.
Build system architecture pmd.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. findbugs.build.xml dist.build.xml build.xml checkstyle.build.xml javadoc.build.xml sclc.build.xml common.build.xml *.build.xml boilerplate code
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
*.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.
Concepts: Properties Targets Tasks Paths Dependent targets build/, bin/, lib/ directory hierarchies Tasks: <project> <target> <tstamp> <javac> <mkdir> <copy> <fileset> <import> <condition> <fail> <available> <javadoc> Key Ant Concepts and Tasks(for now)