"Elements of Ant Style": the ./lib directory

[Ken Gentle]

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!

Ken

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

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: [EMAIL PROTECTED]
=============================================================


--
To unsubscribe, e-mail: <mailto:ant-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@;jakarta.apache.org>