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 Wed, 07 Feb 2001 16:40:36 GMT
I agree about not liking massive build files, but I guess I'm not convinced
that a build file need be more than 10-15K (which I don't consider massive).
In addition, an Ant build file may not need to mention "packages" at all, so
that one build file would be sufficient for your package, my package, and
the Japan guy's package.  And while I also agree that one build file that
requires maintenance can be a "hotspot" in version control, at least in many
cases an Ant file can be made which needs little or no maintenance.  For the
case in which different versions of a class are needed by different people
and you'd like to adjust the order of classpath elements, maybe these people
should be working on different labelled versions of the whole project (just
a thought....sounds dangerous if your project is sensitive to classpath
ordering).

One final note about javac and dependancies.  I definitely do care about
accurate dependancy checking for correct builds because as far as I can tell
javac does not take care of it for us (don't know about Jikes...will have to
check that out).  Maybe I'm not using it correctly, but for me javac will
compile a target file and all the files it depends on if I use the -Xdepend
option; it will not, however, compile other files that depend on the target
file.  I suspect Conor wouldn't have written the <depend> task if this were
otherwise.

Cheers,
David

-----Original Message-----
From: msew [mailto:msew@mail.ev1.net]
Sent: Tuesday, February 06, 2001 12:49 PM
To: ant-user@jakarta.apache.org
Subject: RE: build.xml and .inc file organization/structure


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
buildPackage.inc 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 org.foo.bar.BazIt (version 1) and someone else is using
org.foo.bar.BazIt (version 2 which is NOT backward compatibale with version
1) (and sadly the org.foo 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 org.foo.bar 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.*


msew


*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" <David.Ventimiglia@msdw.com>
Reply-To: ant-user@jakarta.apache.org
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.
>
>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