ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kendall Collett" <>
Subject Re: "Elements of Ant Style": the ./lib directory
Date Sat, 02 Nov 2002 18:40:39 GMT
>From the perspective of performing builds, I prefer to have all the
libraries under SCM (except for those intimately tied with the JDK like
rt.jar).  The primary reason is that I think it makes the build more
repeatable by reducing dependencies on the environment in which the build is
being performed.  For example, you don't have to worry about a build break
where some developer checks in code which builds in their environment (e.g.
because they have a more recent copy of some library).  If you have all the
non-JDK libraries under SCM, then you can specify "ignore" for
build.sysclasspath and pretty much avoid this scenario.

In terms of packaging (or not packaging) libraries for distribution with the
product, I think that's a different, more complicated problem.


PS: In my experience, I don't find bandwidth limitations to be that much of
an issue; since the libraries don't usually change, "cvs update" usually
doesn't have much to do.

----- Original Message -----
From: "Ken Gentle" <>
To: <>
Sent: Saturday, November 02, 2002 12:07
Subject: "Elements of Ant Style": the ./lib directory

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

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

View raw message