Introduction to Software Build TechnologyPresentation Transcript
Introduction to Software Build Technology Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii Honolulu HI 96822
Understand motivation for build and packaging technologies.
Why was running your classmate ’s Robocode robot so hard?
Become familiar with a sample of build technologies.
Get introduced to the build technologies and standards to be used in this class.
Modern team-based, cross-platform development involves:
Multiple developers and users.
System is developed/used on multiple platforms:
Win2K, Linux, Win98, Solaris
Developers/users have different environments:
c:jdk1.5.0_08, d:jdk1.5, c:myjava
Differences between user and developer distributions:
Source distribution for developers
Binary distribution for users
Developers may prefer different IDEs:
Eclipse, JBuilder, Emacs, RationalRose
Users may not have any IDE at all.
Frequent releases and distributions.
Dependence on third party libraries (which may themselves be released frequently).
These issues are not unique to Java development!
Build/packaging techniques should allow:
Users to build and test the system without IDE.
Developers to build and test the system using their IDE of choice.
Developers to build and test the way users build and test.
Configuration to different platforms and different environments within a platform.
Multiple release configurations
Automated build to prevent errors
Rapid release, deployment, testing
Simplified installation and updating of third-party libraries
Our (Java-specific) solution:
A quick tour of build tools
‘ Make’ is the canonical build tool.
File-level dependency analysis
Example: compile only changed files
Unix-based (but ported to other platforms)
Language independent (Java, C++, etc.)
ASCII configuration file syntax
Tab characters required—Yikes!
Supports invocation of any shell command.
Does not support library-level dependency management.
Related: imake, cmake, scons
Java-based build tool by Apache
XML configuration files
Defacto standard for Java projects
Maven is making headway.
File-level, but not library-level dependency management.
Ant vs. Make
Advantages of Make (and related tools):
More popular and widespread
Supports any programming language.
Provides ‘glue’ for invoking any shell command.
Advantages of Ant:
Java-based, active development community
Built-in support for Java and its tools.
build.xml simpler and easier than Makefile.
Simplifies cross-platform Java development
Easier to extend in a portable manner.
Always use Ant over Make for Java-based development
Use Make for other development, at least for now.
“ Project Management” technology
Build based on Ant.
Documentation and reporting plugins.
File-level dependency management
Library-level dependency management
Library repository definition & management
“ Convention over configuration”
Maven builds in conventions for project layout and workflow to simplify use.
Great if you like them.
A “standalone” library-level dependency management tool.
Ant + Ivy =
Much of what Maven offers.
No built-in reporting/documentation
Without Maven “conventions”.
Better representations for dependencies
Ant+Ivy vs. Maven
Very strong feelings on both sides.
Maven is the future; deal with it.
Maven is a black box; customization is much harder than Mavenites portray.
If you can live with Maven conventions, it provides more built-in functionality.
We will use Ant+Ivy
Ant is still more popular than Maven, so it is useful for you to gain experience with it.
Moving from Ant+Ivy -> Maven should not be too bad.
You will also learn some “best practices” for Ant-based projects.
Support for useful third party tools.
Ivy-based library-level dependency management.
Basic Ant concepts
Every project requires an Ant build file
named build.xml by default.
Each build file is composed of targets .
Typical targets: compile, junit, etc.
Each target is composed of tasks
Ex: copy .java files to build/src, invoke javac...
Targets can have dependencies
Ex: modified sources must be recompiled before testing.
Dependent targets are executed exactly once.
test depends upon compile
deploy depends upon compile
all depends upon test, deploy
Compile will be executed only once.
Some targets are executed only when needed.
Sources recompiled only if changed.
Example Ant target
Ant provides a simple, powerful language for building Java-based systems.
How do we use this language effectively?
The next section describes my best approach so far on how to employ Ant to achieve the Three Prime Directives of Open Source Software Engineering.
The “robocode-pmj-dacruzer” example project provides you with a template structure to get you off and running quickly.
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
top-level build file.
“ module” build files, generally one per tool.
the system source files
library files: maintained by Ivy.
derived files: generated by build process
create jar file
run junit tests
build javadoc docs
delete build dir.
create zip dist file.
analyze source code
analyze byte code
analyze source code
compute size of system
compute coverage of test cases.
(Others to be added later in semester!)
Build System Scalability Issues
putting all targets in one build.xml file creates a very large build.xml file that is difficult to understand and maintain.
you may not want to require all developers to have to install every possible third party tool.
dependencies between target and property definitions should be minimal and easily visible.
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
build.xml provides most (but unfortunately not all) of the project-specific definitions:
Most other *.build.xml files can be used with little to no changes.