text: I disagree that one file is not sufficient for a large project with many
  people. Owing partly to Ant's ability to scan multiple directories (the
  original make had trouble even traversing multiple directories), much of the
  heavy lifting of a build process (compiling classes, generating EJBs, making
  JAR files, JavaDocs, etc.) can be accomplished with just a few targets.
  Using the <depend> task helps ensure that you can do correct incremental
  builds so that you can almost always rely on incremental builds. And a
  little judicious use of properties along with the include/exclude attributes
  means that you can easily control and configure what gets built without
  having to hard-code a lot of different targets. In my experience, the only
  case I've seen for multiple build files is when part of the build process
  includes building new Ant tasks that get used later in the build process.
  The article associated with the link below makes a better argument than I
  can for not using a multi-file build approach.
  Cheers,
  David
  -----Original Message-----
  From: msew [mailto:msew@mail.ev1.net]
  Sent: Tuesday, February 06, 2001 11:41 AM
  To: ant-user@jakarta.apache.org
  Subject: build.xml and .inc file organization/structure
  So when I was playing with xml a while back one of the things that greatly
  angered me was the inability to effectively organize xml files into a
  hierarchy or set that actually makes sense. Now maybe I just don't
  understand all of the Xinclude stuff that is being created but it seemed
  that there was a real lacking of any way at all to have something like
  subdoc from sgml in xml. The question for ant users is:
  how on earth do you all organize all of your build files? For smallish
  projects with one or two people working on it you MIGHT get by with only
  using one build.xml file. But when you are doing a larger project with many
  people one file is just not acceptable at all.
  Bascially, I want to do something along the lines of:
  -classpath files
  -property files
  -target files
  -specific package build scripts
  -global build script
  the idea being that I can reuse all of my build script components easily for
  both, global and local, and various meta combinations.
  ie:
  classpath files:
  globalLibClasspath.inc
  packageLibClasspath.inc
  packageClasspath.inc
  obfuscatorClassPath.inc
  fooClasspath.inc
  property files:
  globalProperties.inc
  packageProperties.inc
  fooProperies.inc
  target files:
  globalTargets.inc
  packageTargets.inc
  fooTargets.inc
  Then those are all the components/parts I can use. So I make a packageLevel
  Build script that is:
  (all the .inc would get an !ENTITY entry)
  <!DOCTYPE project [
  <!ENTITY foo.inc SYSTEM "foo">
  ]>
  <project name="foo" default="usage" basedir="." >
  &globalLibClasspath;
  &packageLibClasspath;
  &packageClasspath;
  &globalProperties;
  &packageProperties;
  &packageTargets;
  </project>
  and that is build file for THAT package. The package owner can make all the
  build files and make his packageLevel build AND he can edit the global make
  file to have his various .inc files so that when he changes them boom the
  global doesn't have to change at all it just gets the newest versions via
  the !ENTITY.
  Now I can easily re-use those components to make a build script for a set of
  packages or for a global file.
  The issue being that I have to retype the !ENTITY entry in each build.xml
  file that I make :( Which really sucks but I don't see a way around it
  really ( PLEASE correct me if I am wrong here ). Further there is the
  naming problem (we can maybe get around this using namespaces, but even so
  one can just be facist and make people name their stuff with their fully
  qualified package name or something (not that big of deal here really ).
  Is there any way to do what was outlined above? Or if I am just doing
  things totaly whacky? What are others doing to make an attempt at being
  able to reuse build components? And allow the easy additition of new
  packages into your global build process?
  thanks
  msew