ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David McTavish <>
Subject RE: Scaling to large projects
Date Mon, 03 Feb 2003 19:03:53 GMT
However, in most deployments, I'm assuming that this isn't the norm, and
sometimes not even possible.  We have been following Apache's directory
structure, where each major project gets its own top-level folder. Our first
implementation was messy, but after 4 months of refactoring and cleaning,
its quite manageable. We have a build.xml file in each major project, as
well as one at the top-level directory. (I believe you could also use other
tools like maven to manage multiple projects, however, I found this beyond
what we needed, and I wasn't overly fond of the project configuration files.

So, we have the following directory structure:

 +-- project1
 |   |
 |   +-- build.xml
 |   |
 |   +-- src
 |   |
 |   +-- lib
 +-- project2
 |   |
 |   +-- build.xml
 |   |
 |   +-- src
 |   |
 |   +-- lib
 +-- build.xml
 +-- scripts
     +-- common-build.xml

The root level build.xml file just aggregates calls to the child node for a
specific target, and uses a <target>.<project> naming convention. ie: to
compile project2, you would issue the command "ant compile.project2".

The build.xml files in each project folder are very simple, but contain
build details that are very specific to each project (ie: project1 requires
a bsd install tool, project2 must be compiled using the gcc compiler, ...).
I've used a common target naming practice to ensure that every project
contains a core group of targets, to make dependency imports that much
easier. (This basically comes down to requiring a build and a
build.interface target, where the build.interface will package the external
interface for other projects to import properly).

The only tricky part was when projects depended on other projects. I've
refactored this to basically two lines per dependency in each build script.
One to add the library to the compile classpath, and another inside the
dependency of the compile target which imports the libraries to the local
lib folder. I've refactored this such that it only requires two variables,
the path to the dependent project, and the name of the archive to copy to
the local lib folder. This means that you have to manually manage the
dependencies between projects, which is more of a philosophical difference
that I don't care to delve into at this point.

Anyway, if you care for some sample scripts on what I've done, feel free to
write me personally.

-----Original Message-----
From: M. Erik Husby []
Sent: Monday, February 03, 2003 1:37 PM
To: Ant Users List
Subject: Re: Scaling to large projects

The simplest way to scale to a large project is to organize your directories
in a fashion 
similar to this:


   - src
      (all package sources)

   - classes
      (where all class files will end up.)

   - lib
       (where all third party jar files live)

   - deploy
       ( where you put the deployable files )

Then your build.xml can contain things like:
<path id="base.path">
  <pathelement location="./classes"/>
  <fileset dir="./lib">
   <include name="**/*.jar"/>

<javac destdir="./classes">
 <classpath refid="base.path"/>

Javac will compile everything under the source directory. You are free to
add packages and refactor
classes as you see fit.

Erik Husby

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message