ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "msew" <>
Subject build.xml and .inc file organization/structure
Date Tue, 06 Feb 2001 19:40:32 GMT
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.


classpath files:

property files:

target files:

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 SYSTEM "foo">

<project name="foo" default="usage" basedir="." >





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? 



View raw message