Project vs. developer configuration options
You may have noticed that there really isn't anything in that first example
build file which is specific to the project being built: this build file can
be reused for any project. Obviously it helps that this build does nothing
more than compile Java source into class files. Once you want to build jar
files you'll need to include project specific information such as the name
of the jar file to create.
So let's make a new properties file, checked into CVS, which contains values
which are common to a particular project and shared by all developers. As long
as we're making a project-specific properties file, we can also set default
values for developer specific options, so they only have to define those
properties they specifically want to change. Ideally this will make the build
work out of the box - the developer checks out the project code and build file,
and can immediately build the project with defaults. If they want to change
compilation options, paths, etc. then they can override those options as
they please.
To do this we may have properties which are defined twice, once with the
default value and once with the developer's chosen value. Ant doesn't allow
properties to be overridden once set, so we will first read in the developer's
choices for property values. After this the default values can be read in,
filling in any properties which haven't already been set, and leaving those
properties set by the developer untouched.
The following example extends previous examples to create a Jar file, using a
default.properties file shared by all developers on the project, and a
build.properties file with which developers can override the defaults. The
default.properties file is checked into CVS, and only needs to be changed
when the build needs to be changed for everyone. The build.properties is created
by each developer, and not shared.
<project name="build3" default="jar" basedir=".">
<property file="build.properties"/>
<property file="default.properties"/>
<target name="init">
<mkdir dir="${build.dir}" />
</target>
<target name="compile" depends="init">
<javac srcdir="${src.dir}"
destdir="${build.dir}"
debug="${debug}"
optimize="${optimize}"
deprecation="${deprecation}">
<include name="**/*.java" />
</javac>
</target>
<target name="jar" depends="init,compile">
<jar jarfile="${build.dir}/${project.name}-${project.version}.jar"
basedir="${build.dir}" />
</target>
</project>
Aside from the new "jar" target, this version introduces properties to define
the name and version of the project. The default.properties file has values for
these and the other properties. By assuming that the source and build directories
are subdirectories of the directory containing build.xml, any developer should
be able to build the project out of the box by checking out the source code,
build.xml, and default.properties. They only need to create build.properties
if they want to override these. Here is a default.properties file for
ourProject 2.2:
project.name = ourProject
project.version = 2.2
build.dir = ./build
src.dir = ./src
debug = on
optimize = on
deprecation = off
A developer who doesn't like building project output in the project directory
can make a build.properties file to override the build.dir property, so the
output directory will be created and populated somewhere else:
build.dir = ../ourProjectBuild
Organizing your project with CVS
For information on downloading, installing, and using CVS, the best resources are
the CVS site documentation
and the Coriolis CVS book, which is
available for free online. GUI clients for Windows
and Mac are also available.
As projects grow in size and complexity, a single repository often becomes
unwieldy. This is especially true when subgroups of the developers work on
different parts of the code, since they have to check out and build unnecessarily
large chunks of source. It may make life easier to split these projects into
multiple sub-projects, each as a separate CVS project. Note that this doesn't
mean developers can't dip into other subproject source from time to time, just
that they don't normally check out and build large parts of the project that
they seldom work on.
An obvious situation that requires this division is when multiple application
projects depend on a single set of code, for example reusable components or
a framework. The shared components should not be developed in the same repository
as an application, but should instead have their own repository, building
distribution jar files which are then incorporated into the dependent
applications.
Another common situation is where portions of the code are logically separated,
and even separated by the skill sets of subteams developing them. Web
applications are often this way, with code divided into storage/database,
business/application logic, and presentation/display. For these projects,
template developers skilled in HTML, JavaScript, and other display-oriented
technologies will have their own repository, using jar files and other products
from the back-end developers, rather than working with all of the code lumped
together.
Sometimes the files kept in a single project repository simply become too
numerous, so that CVS operations are too time consuming, so you need to get
creative to figure out ways to divide files into more manageable groups.
For example, when developing a graphics-intensive website it can be handy to
keep the image files in CVS, but these tend to be large and CVS is slow
handling them. Splitting the graphics into a separate subproject from the
HTML templates can streamline the development process in this case.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
