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 20:48:36 GMT
I personally don't enjoy working with an 100k+ file.  That is just me tho.  Further putting
things in one huge massive file does NOT work in a distributed environment very well at all.
 When I am working on my package I don't care about your package and I certainly don't care
about the package that the guy over in japan is working on.  When I am done with my module
ALL I want to do is say: here is how you build my file.  A simple is all
I should have to point you towards.  All arguments of version control and merging files and
dealing with that one guy that likes to lock the single file we all need to use aside, one
file that everyone needs and is updates frequently is BAD BAD BAD.

Further, when people are using different versions of the same class (ie I am using
(version 1) and someone else is using (version 2 which is NOT backward compatibale
with version 1) (and sadly the people didn't follow the rules for versioning components
and kept the same method names with same arguments!) )  this is going to get really hosed
in the single 100k makefile. "What is the classpath again?  Which order does the
jarfile appear?"   I don't see any functionality in ant to check the classpath for ordering
of classes  (possible feature request here).  

Basically you still HAVE to explicitly set up your own classpath per target to make certain
that some other target before you has not munged the classpath var.  

I read the "recursive make considered harmful" 2-3 years ago and while it makes decent points
most of non philosophical pts deal with performance issues, dependencies (we do NOT CARE about
this in java as javac takes care of it for us) and the fact that you have to physically go
about changing directories for make to work and maintaining that really sucks.  (ie in ant-world
your package has a property called: fooPackageBaseDir and it is a fully qualified path to
where that package is located.  And ant uses that as it's base dir.  No silly ../../../../
or was it ../../../  stuff ). 

With package based building, where those packages are basically 100% seperated from each other,
this article doesn't really say anything to suggest that making it easier on the developers
integrating into the global build and being able to reuse things is a harmful.  Nor does it
really touch upon working in a distributed environment where people may not even be connected
or in contact until way down the road when you need to integrate their stuff into the make
system.  I would rather add 2 lines to import his stuff than having to add another 10k worth
of text to the global make file.

remember javac != gcc (javac finds all the dependencies for us as long as they are on the
classpath!) :-)

So in summary:  GREAT article that is not really applicable to java development with ant taking
the place of make.*


*don't use ../../..  or was it ../../../..  type directory referencing as it assumes something
that may not always be true  was the one thing the article touches upon that DOES hold true
for ant/javac developing.

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