ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ventimiglia, David" <David.Ventimig...@msdw.com>
Subject RE: build.xml and .inc file organization/structure
Date Tue, 06 Feb 2001 19:55:07 GMT
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

http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html

-----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

Mime
View raw message