ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "msew" <>
Subject RE: build.xml and .inc file organization/structure
Date Tue, 06 Feb 2001 21:35:39 GMT
oh it probably is sufficient.  But I dislike working with 100k+ sized files.  I also don't
really enjoy having a single file that is the sole point of contention amongst a distributed
development team.  We ALL know that one person that just has to lock file and then go away
for a 4 day weekend.  AIEIEIEIEI    I also don't enjoy having the global classpath of doom
being used for my one package (suffering as javac scans across ALL the thousands of classes
is maddening).

Also when I am working on my indiv package I really should not have to be in contact with
the global uber make file.

Further, the issue of classpath conflicts seems a very real thing when you have all your stuff
in massive file.  I use (version 1) and bob uses (version2).
 Sadly the people didn't change their method names in the new version and they take
exactlty the same arguments.  DAMN THEM!!!  So now, unless I reset my classpath each time
and specifically set it, I have a very real chance of running into problems.   And as soon
as you start reseting your classpath and having package based classpaths the one big file
begins to look like 




where each of those has the required set up.

I read the "recursive make considered harmful" 2-3 years ago when it first came out.  Aside
from the philosophical points it makes I really don't see much in terms of applicability to
the ant/javac world.*  And all of the performance jabs it takes at make needing to double
compile, and how slow it is when reading in multiple .inc files, really are not applicable
at all to us.

* one thing that is always true no matter which build methodolgy you use is the painful ../../../foo
or was it ../../../../foo  problem.  

javac != gcc    (javac automagically finds the dependancies and compiles them gcc does not
and thusly needs make to do it for it)

ant is not blithely cd .. and cd foo/bar invoc self, oh this new make sez I need to read in
the  ok read that in.  ok wow I don't do anyhting here cd ../../.. then make
again     (all those ../.. are just a maintenance nightmare )

So while it is a GREAT paper I don't see it saying anything that leads me to believe using
&includedFile;  is a bad bad bad thing.

I do know that the XML tools for including other files into .dtd/.xsd or even into .xml files
all SUCK a lot and wondering what people use now.


---------- Original Message ----------------------------------
From: "Ventimiglia, David" <>
Date: Tue, 6 Feb 2001 11:55:07 -0800 

>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.
>-----Original Message-----
>From: msew []
>Sent: Tuesday, February 06, 2001 11:41 AM
>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.
>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