>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. Kendall 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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 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). -- To unsubscribe, e-mail: <mailto:ant-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ant-user-help@;jakarta.apache.org>
