ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Gentle <>
Subject "Elements of Ant Style": the ./lib directory
Date Sat, 02 Nov 2002 18:07:24 GMT
I've finally received my copy of "Java Development with Ant", and want to 
thank Steve and Erik for a great reference!

Having used ant for several years now on varying sized projects, I was very 
interested in the section on "Elements of Ant Style" (Appendix D) to see 
how the conventions I've learned/developed stack up against the experts.

I'm generally in agreement with these suggestions, but one stands out as 
diametrically opposed to my common practice.  in section D.4.5, Directory 
Structure, the recommendation is to keep library files "with the 
project".  As most projects are managed from some type of SCM tool, that 
kind of implies keeping those lib/jars in the SCM system.

I've always resisted putting libraries into SCM for a particular project, 
especially if there are related projects that share those same 
dependencies.  I tend to install the libs to a single location (/opt/lib 
and /opt/tools (lib for run-time dependencies, tools for, well, tools!)), 
then share that location so that is accessible by all developers and 
development boxes.  If a developer wants a local copy to improve access 
times, OK, but it is the developer's responsibility to keep up with changes 
to the "authoritative" source (Y.O.Y.O.M.F.)  A single Ant properties file 
is all that is needed per project to pull in the appropriate version of a 
lib from the right place.

Including the libs with each project, and having all of that under SCM, 
seems to be wasteful of bandwidth and disk space.  These libraries don't 
change often relative to project source code, and things that don't change 
shouldn't be under SCM -- they're documented as external 
dependencies.  I've worked from repositories that include the "lib" dir as 
described and suffered through CVS bringing down the whole 5+ mb lib dir 
over a slow link -- especially when I already have a copy of the lib 
locally.  It also seems to encourage deploying and distributing these 
dependent libs, giving us yet another flavor of "DLL Hell".

I'm in the process of setting up the build environment for a new 
employer/project (why do *I* always seem to end up doing this?), and the 
other senior guy on the team leans towards including the "lib" stuff in the 
project SCM.  I'm willing to be talked out of my bias, I think, but I'd 
like to hear some other opinions and practices around dependent libs.   I 
know that I'm tired of having yet another copy of jaxp/xalan/xerces 
downloaded with every new open source project I'd like to use.

So what is the general consensus?  Include them or not?  Please explain the 
reasoning or experience that made you lean one way or the other.

         Thanks in advance!


P.S.:  This idea (distributing/SCM'ing the lib dependencies) seems so 
reminiscent of the static versus dynamic linking debate for compiled 
languages in the 80's.  Static linking resolves all dependencies during the 
build, but bloats the executable -- dynamic linking reduces code size and 
enables more re-use of resources, but introduces dependencies on the 

P.P.S: Seems to be rearing its head again in the J2EE space (include all 
the dependencies in the war/ear jar).

J. Kenneth Gentle (Ken)    |  Email:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message